Re: [jamboost] Re: Boost.build gcc question

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-01-08 22:34:36

On 2002-01-08 at 09:49 PM, david.abrahams_at_[hidden] (David Abrahams) wrote:

>
>----- Original Message -----
>From: "Brian Mosher" <bmosher_at_[hidden]>
>
>
>> Dave,
>>
>> We're looking to switch from our own Jam-based build system to boost.build
>> for our internal build system.
>
>Wow, cool!
>
>> We've got everything building, but on the gcc
>> solaris port I've run into a question.
>>
>> Our solaris/gcc build has a dependency on libstdc++. In order for the
>> runtime loader to find libstdc++.so, it needs to find a DT_RPATH array tag
>> entry in the dynamic section of the elf program header. This entry
>consists
>> of a runtime library search path. From what I can tell this path should
>> include /usr/local/lib for most standard installations of gcc/glibc on
>> solaris.
>
>So, if I understand you correctly, you want to use this technique which
>hardcodes (all? part of?) the runtime library search path (usually supplied
>by LD_LIBRARY_PATH) into the executable itself.
>
>> As I understand it, there are two common ways of getting the linker to add
>> this path entry to the executable.
>>
>> 1. Setting the environment variable LD_RUN_PATH to the desired search path
>> or
>> 2. Passing the -rpath <dir> switch to ld on the command-line during the
>> link.
>>
>> I am currently using the first method. I would like to switch to the
>second
>> technique though so that things will be handled correctly without the
>> environment variable, however I am concerned about breaking what is
>already
>> in place.
>>
>> I see recently(1/3/02) that you added:
>>
>> gRUN_LD_LIBRARY_PATH($(<)) += $(GCC_STDLIB_DIRECTORY) ;
>>
>> to the gcc-tools.jam and I wasn't sure exactly what this change was doing.
>> Is gRUN_LD_LIBRARY_PATH a variable? If so, it doesn't seem to be
>referenced,
>> only set.
>
>See line 146 of boost-base.jam.
>
>gRUN_LD_LIBRARY_PATH(<some-target-name-here>) is a variable. It is used to
>form a path for running <some-target-name-here> (and, if that's a dynamic
>lib, other targets which depend on it) through the build system. For
>example, the testing rules in status/Jamfile (current CVS) use it. Also see
>the execution rules in python.jam. It's not currently intended for
>hardcoding library paths.
>
>> I have a feeling that this may be similar to the change I need,
>> but I'm not familiar with what's happening here.
>>
>> Any suggestions to keep me from screwing up my gcc-tools.jam?
>
>I think the build system needs at least one change, possibly more:
>
>First, and most obviously, we have <cflags> and <cxxflags> features which
>can be used to force toolset-specific flags into the compiler's
>command-line, but we have nothing similar for linking. There should be a
><linkflags> feature. That would get you out of trouble quickly. If you add
>it, please add it in the obvious way to all toolsets and send me a patch.

Interesting, I started adding the <linkflags> to my version this past weekend
:-) Brian if you want, and are willing to wait a few days, I'll post the
changes.

>Secondly, we might want a feature that says "this particular library
>dependency should be hardcoded in the executable". I'm not sure whether that
>can be normalized, though: msvc has a mechanism but AFAIK it is very
>different. Maybe someone will correct me.
>
>Finally, we might want a feature that says, "hardcode all the dependencies
>computed in gRUN_LD_LIBRARY_PATH into the executable".

If you are talking about hardcoding the path of a library dependency's
directory I don't think that will help Brian out much. That would only encode
the directory as in the build, grist dirs and all, which is not usefull for
delivery, where the program and it's files are in totally different places. Or
am I not getting it?

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]