[Scons-users] SCons always uses relative path even when absolute path is set with LIBPATH

Matthew Bernard matt.s.bernard at gmail.com
Fri May 25 14:08:52 EDT 2018


That's right. in the sconscript I assign a build directory variable to be:
common_build_dir = '/Users/..../sConstructDir/build/common'

and then in the sharedlibrary call my code is

    tpr_lib = env.SharedLibrary(target = 'dynamic_lib',
                                source = srcs,
                                LIBS = 'common',
                                LIBPATH= common_build_dir,
                                RPATH = common_build_dir
                               )

so that during the linker stage I would expect to see

gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib [object
files]  -L/Users/..../sConstruct/build/common -lcommon

but during the linker stage in the build-cmds output it is reported as

gfortran -o build/dynamic_lib/libdynamic_lib.dylib -dynamiclib [object
files]  -Lbuild/common -lcommon

In the github issues chat you suggested modifying my changing the type of
common_build_dir from a string to a Dir class which I did but it didn't
unfortunately it didn't change the build commands that were actually called.

Thanks Matt



On Fri, May 25, 2018 at 12:04 PM, Bill Deegan <bill at baddogconsulting.com>
wrote:

> So the flags are correct, but for your case the values provided to them
> are incorrect?
>
> On Fri, May 25, 2018 at 8:49 AM, Matthew Bernard <matt.s.bernard at gmail.com
> > wrote:
>
>> Hey Bill,
>>
>> It seems like scons already provides the interface to do this through the
>> LIBPATH and RPATH constructor variables. When I add them to the shared
>> library object it produces the correct linker flags, it is just that it
>> removes all of the directory structure that that I build up to have it
>> register the dylibs with eh absolute path.
>>
>> Matt
>>
>> On Fri, May 25, 2018 at 11:45 AM, Bill Deegan <bill at baddogconsulting.com>
>> wrote:
>>
>>> Matt,
>>>
>>> If you can figure out the appropriate flags to the linker to resolve
>>> this then it shouldn't be to difficult to make some changes to your build
>>> Environment() to resolve this issue.
>>>
>>> -Bill
>>>
>>> On Fri, May 25, 2018 at 8:42 AM, Matthew Bernard <
>>> matt.s.bernard at gmail.com> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> I submitted an issue on GitHub a couple days ago at the link below
>>>> which provides some background on my issue as well as important outputs
>>>> from my build.
>>>>
>>>> Systems Notes:
>>>> Currently developing on MacOS
>>>> python version: 2.7.14
>>>> scons versions: custom scons based on 2.1.0 and 3.0.1
>>>>
>>>> https://github.com/SCons/scons/issues/3128
>>>>
>>>> A brief history of my problem is that I develop a code which has used
>>>> scons to compile an application for many years. Recently, we started some
>>>> work which has required us to repackage our code to be compiled as a shared
>>>> library to be linked in with another code which uses make.
>>>>
>>>> I was able to modify our scripts to output the dylib files but they
>>>> won't link into the higher program because all of the dependent dylibs are
>>>> registered using relative paths. In the brief discussion that I had on
>>>> GitHub, I was told this is expected behavior which puts me in a bind
>>>> because my code is comprised of 7 projects which depend on each other to
>>>> various degrees.
>>>>
>>>> I have done quite a bit of research and found that there are tools
>>>> available for linux and Mac which can postprocess the shared libraries to
>>>> reregister the shared libraries using absolute paths but I would prefer to
>>>> do this work within scons if at all possible.
>>>>
>>>> Thanks for your help
>>>> Matt
>>>>
>>>> _______________________________________________
>>>> Scons-users mailing list
>>>> Scons-users at scons.org
>>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Scons-users mailing list
>>> Scons-users at scons.org
>>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>>
>>>
>>
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20180525/a963ac1b/attachment-0001.html>


More information about the Scons-users mailing list