Scons adds disk name prefix to NFS LIBPATH

Hi I'm building environment with Scons. For Windows platform (link) linker gets Scons setup of my share library path with prefix - disk name

I've library on NFS:

libs='\\\\share\\lib\\lib'

In scons I have:

env.Append(LIBPATH = [libs]) 

result is that the linker invokes something like this:

/LIBPATH:D开发者_运维问答:\share\lib\lib

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 get out of python \escape-hell, you can use the string prefix r which stands for "raw" and all your \'s will be passed through unmolested.

env['LIBPATH'] += r':\\share\lib\lib'

EDIT: In response to the author's comment and in order to debug this further try:

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'] on the last print, then something else in scons is mangling your input. If the string you want to append to the lib path is incorrect, try manipulating the string in the python interpreter. Do <Windows start> -> <Run ...>. Then type 'python'. This should give you an interactive python terminal and you can experiment with string manipulation. If doing that sequence of commands doesn't work, you can try to find your python install someplace and double-click the python.exe file.

The root of the problem here is that SCons adds the libs found in the LIBS array to the linker commandline -- with full path. This results in the linker saving this full pathname into the generated executable, which is unfortunate, especially if we're building some libs which will be installed into a system directory later on. I'm not sure if we can blame SCons for that, because the linker needs to find the library for linking against it.

I could only find the following two solutions up to now:

• build the libs and the executable in the same build directory, move the generated files afterwards (e.g. with the Install() builder). This results in just the name of the library ending up in the executable
• link against already installed libraries in system directories and use the mechanisms for configuring the right dependencies

both solutions seem somewhat awkward....

PS: (edit) there is a non-portable solution though. You may pass specific options to the linker. Especially, on a GNU/Linux system, you may explicitly set the DT_SONAME with the -h option. When a library contains this explicity set DT_SONAME field, then any referrals in other libs or executables will just use that name -- leaving the exact resolution to the linker at invokation time. Usually this is exactly what we want, when building a new library to be installed later into the system