Re: Boost.build gcc question

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-08 21:49:54

----- 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.

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".

HTH,

Dave