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

Bill Deegan bill at baddogconsulting.com
Sun May 27 16:18:17 EDT 2018 

O.k try adding this:
env['__RPATH'] = '$_RPATH'

See if that resolves it.


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

> 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
>>
>
> _______________________________________________
> 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/08a948c7/attachment-0001.html>

More information about the Scons-users mailing list