[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:45 EDT 2018 

or at least gets the -W-l... flag on your command line.
(can you hop on the IRC channel?)

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

> 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/7b33b1fe/attachment.html>

More information about the Scons-users mailing list