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

[Bill Deegan]

How are you installing gfortran on your mac? macports? brew? other?
(trying to replicated your environment)

On Sun, May 27, 2018 at 12:32 PM, Matthew Bernard <matt.s.bernard at gmail.com>
wrote:

> Yep. That’s right. That would resolve my issue by letting the external
> application link my code and its  dependent libraries from where the
> external
> Application is compiling.
>
> Thanks for spending time on this.
> Matt
>
> On Sun, May 27, 2018 at 2:46 PM Bill Deegan <bill at baddogconsulting.com>
> wrote:
>
>> 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
>>>
>>>
>> _______________________________________________
>> 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/f7191c66/attachment-0001.html>