Scons prefix the drive name to the NFS LIBPATH
Hi I am creating an environment with Scons. For Windows platform (link) the linker gets the Scons setting of my shared library path prefixed with the drive name
I have a library on NFS:
libs='\\\\share\\lib\\lib'
In scons, I have:
env.Append(LIBPATH = [libs])
the result is that the linker calls something like this:
/ LIBPATH: D: \ folder \ Lib \ Lib
source to share
It looks like the Append function is changing your input. Have you tried manipulating "LIBPATH" through the __set_item__ interface? Try:
env['LIBPATH'] += ':'+libs
or
env['LIBPATH'] += ':\\\\share\\lib\\lib'
Also, if you want to quit python \ escape-hell, you can use the string prefix r which means "raw" and all your \ will be passed through unmolested.
env['LIBPATH'] += r':\\share\lib\lib'
EDIT: In response to the author's comment and for debugging this additional attempt:
append_lib_path = r':\\share\lib\lib'
print 'DEBUG: append_lib_path is', append_lib_path
print "DEBUG: before appending to env['LIBPATH'], env['LIBPATH'] is ",env['LIBPATH']
env['LIBPATH'] += append_lib_path
print "DEBUG: after appending to env['LIBPATH'], env['LIBPATH'] is ",env['LIBPATH']
If you see the correct value in env ['LIBPATH'] the last time you print, then something else in scons mangles your input. If the line you want to add to the lib path is wrong, try using the line in your python interpreter. Run <Windows start> → <Run ...>. Then enter "python". This should give you an interactive python terminal and you can experiment with string manipulations. If this sequence of commands doesn't work, you can try to find your python to install somewhere and double-click the python.exe file.
source to share
The root of the problem here is that SCons adds the libraries found in the LIBS array to the linker command line - with the full path. This causes the linker to store this fully qualified pathname in the generated executable, which is unfortunate especially if we create some libraries that will later be installed in the system directory. I'm not sure if we can blame SCons for this, because the linker needs to find a library to link to.
So far, I could only find the following two solutions:
- create libraries and executables in the same build directory, move the generated files (for example, using the Install () constructor). This only results in the name of the library ending in the executable
- link to already installed libraries in system directories and use mechanisms to set up correct dependencies
Both solutions seem somewhat awkward ...
PS: (edit) there is a non-portable solution. You can pass specific parameters to the linker. In particular, on a GNU / Linux system, you can explicitly set DT_SONAME with the -h option. When a library contains this field to define a DT_SONAME, then any referrals in other libraries or executables will simply use that name - leaving the exact permission for the linker at activation time. Usually this is exactly what we want when creating a new library that will be installed later on the system
source to share