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

Sun May 27 16:12:46 EDT 2018

GFortran (as a part of the gcc suite) is compiled  from the MOOSE framework
which is the external application that my code is being merged with.

They exclusively use Make but my application is mostly Fortran so we really
rely on scons to resolve the dependencies.

On Sun, May 27, 2018 at 4:07 PM Bill Deegan <bill at baddogconsulting.com>
wrote:

> 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
>>
>>
> _______________________________________________
> 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/0ea18a82/attachment.html>