absolute library path handling issue
This issue was originally created at: 2013-07-22 18:23:46.
This issue was reported by: brianw1.
brianw1 said at 2013-07-22 18:23:46
When specifying an absolute path to a library, the extension is stripped resulting in gcc being unable to find the file.
Example:
env = Environment(LIBS=['/usr/lib/foo.so'])
This becomes
-l/usr/lib/foowhen given as an argument to gcc rather than-l/usr/lib/foo.soOf course, including
/usr/lib/foo.soas a source file works properly but in this case I am getting libraries frompkg-config --libs pkg_namein the form-l:/usr/lib/foo.soand using ParseConfig which places these in theLIBSlist.My current workaround is to filter out all libs with a ':' prefix and instead include them as source files after all my sources.
Note that the ':' is used to prefix the lib path because pkg-config will otherwise re-order libs by moving those without a
-lprefix to the front.
brianw1 said at 2013-07-22 19:02:02
Correction, I missed the leading ':' in the example.
Example:
env = Environment(LIBS=[':/usr/lib/foo.so'])
This becomes
-l:/usr/lib/foowhen given as an argument to gcc rather than-l:/usr/lib/foo.so
ajf58 said at 2014-08-17 08:36:15
The documentation for SCons 2.3.2 http://www.scons.org/doc/production/HTML/scons-user.html#cv-LIBS is that to do this you could use a File object in the list. Given that you're using pkg-config I'd recommend using the ParseConfig function http://www.scons.org/doc/production/HTML/scons-user.html#sect-parseconfig.
I'd suggest this issue is marked as won't fix, unless anyone objects?
Isn't there another issue on this topic? The gcc leading-colon syntax is not currently recognized by SCons.
See also issue #2743, #2925 and #3951. I'm thinking we should be able to collapse these down to one (or maybe just close all four with one PR).
So now we have (documented, once 4.6 releases) two ways to give more "literal" paths, which aren't first stripped by SCOns - the : introducer from the GNU linker, set via LIBLITERALPREFIX, and using a File object. Closing this as fixed via #4429.
Hmmm, reopening for now. Would like to check if a library specified this was from pkg-config is handled by ParseFlags - in theory it should work but is untested.
Okay, can manually confirm this works - if the string returned by pkg-config contains the literal-library syntax, it is passed through the chain and ends up correct, like this sample:
scons -n -Q
gcc -o hello.o -c -DSOMETHING -DVARIABLE=2 hello.c
gcc -o hello hello.o -L/usr/lib -lother -l:libliteral.a
So I will close this one (if someone thinks a formal test is needed for that, feel free to reopen)