building boost on Solaris with gcc

[joern.clausen@…]

The following change is necessary to compile boost on Solaris using the native linker. It will probably not work when using GNU binutils, but as the other OSes are checked unconditionally as well, I think this is only fair.

--- ./tools/build/v2/tools/gcc.jam 2008/11/28 13:08:45 1.1 +++ ./tools/build/v2/tools/gcc.jam 2008/11/28 13:10:20 @@ -149,6 +149,10 @@

{

linker = aix ;

}

+ else if [ os.name ] = SOLARIS + { + linker = sun ; + }

else {

linker = gnu ;

I find this comment from sun.jam a little bit confusing:

# On gcc, there are separate options for dll path at runtime and # link time. On Solaris, there's only one: -R, so we have to use # it, even though it's bad idea.

Even more as a few lines below, both -L and -R are used, which clearly demonstrates that separate library paths for compile time and run time are supported.

[Vladimir Prus]

This was fixed in r49619. As for -L/-R: on Linux, there are three options -- good old -L, and two options that affect dynamic linking -- -rpath and -rpath-link. To the best of my knowledge, Solaris has a single -R option.

[anonymous]

For the record: Solaris has two options: -L defines the link time path, -R (or -rpath or -Wl,-R, or whatever your compiler will pass on) defines the run time path to search for shared objects. Defining only one of these two is usually wrong, normally you have to define both. And in most cases, both paths are identical. Typical exceptions are if you link against a library you are about to install later, or if you are building for a chrooted environment. See

​http://docs.sun.com/app/docs/doc/817-1984/chapter2-88783

chapters "Directories Searched by the Link-Editor" and "Directories Searched by the Runtime Linker".