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

Bill Deegan bill at baddogconsulting.com
Sun May 27 14:46:00 EDT 2018


It looks like you want the following in your command line for linking the
shared library:

gfortran -Wl,-rpath,$RPATH -o build/dynamic_lib/libdynamic_lib.dylib
-dynamiclib [objectfiles]  -Lbuild/common -lcommon

Does that sound right?
(Where your RPATH is an absolute path)

On Sun, May 27, 2018 at 11:35 AM, Matthew Bernard <matt.s.bernard at gmail.com>
wrote:

> My problem is that rather than using scons to build an application as we
> did in the past, I am now building a set of shared libraries for an
> external application to reference. Scons is linking all of the libraries
> together properly but because the dependent libraries are registered with a
> relative path based on where the sconstruct file is, the external
> application fails to properly link the libraries.
>
>
> The external application can properly reference everything through the -L
> flag as you said, but the top level shared library (which we used to just
> compile as an application) can’t find its dependent libraries which is
> resolved if the files are registered with an absolute path.
>
> We would prefer not to resort to using LD_ Library_path as it is not
> secure and we will be installing this code onto clusters once these build
> problems are resolved so we will not have the ability to control those
> flags anyway.
>
> I know it is an odd use case but I would really prefer to keep using scons
> for this special case because we have built up a large set of supported
> configurations for our code when compiling a application. If it isn’t
> possible to do this through input, could you point me at the part of scons
> that normalizes path strings?
>
> Thanks
> Matt
>
> On Sun, May 27, 2018 at 1:57 PM Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>> What's the proper flag to specify RPATH?
>>
>> On Fri, May 25, 2018 at 12:52 PM, Mats Wichmann <mats at wichmann.us> wrote:
>>
>>> On 05/25/2018 12:08 PM, Matthew Bernard wrote:
>>> > 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
>>>
>>> Having trouble understanding what the problem is... why do you want to
>>> put an rpath into the library in the first place? that means you're
>>> hardcoding a place the dynamic linker will look for the library's own
>>> library dependencies - at runtime.  If you made that the same as your
>>> build location, that means the final binary will always need that build
>>> area to be present, or the libraries won't be found. Unlikely to be
>>> right for production.  This is nothing to do with scons, and nothing to
>>> do with whether the rpath is relative or absolute, although arguably the
>>> problem is more complex if it's relative.  If you use an rpath, it
>>> should point to the place where the libraries are going to be
>>> /installed/, not where they're built.  This has nothing to do with
>>> finding the dependent libraries at link time - when you do your second
>>> link in the project using Make.  That link has to have -L instructions
>>> to point to where to find those libraries for linking purposes.
>>>
>>> I know the Mac has funky extra stuff, look up @executable_path. Not a
>>> Mac user so don't know what's going on with that.  Otherwise, instead of
>>> rpath you can use LD_LIBRARY_PATH (with caution) on linux,
>>> DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH on Mac.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20180527/b008ddff/attachment-0001.html>


More information about the Scons-users mailing list