Re: [boost] building shared boost libraries

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-03-02 16:48:48

On 2002-03-02 at 03:32 PM, steven.robbins_at_[hidden] (Steve M. Robbins)
wrote:

>On Mon, Jan 14, 2002 at 08:43:33PM -0500, David Abrahams wrote:
>> 
>> ----- Original Message -----
>> From: "Steve M. Robbins" <steven.robbins_at_[hidden]>
>> 
>> > > > Suppose then that the next "foo" release changes the ABI.  Then the
>> > > > shared object must change SONAME.  For example, it may be in a file
>> > > > named "libfoo.so.2.0.0", with a SONAME of "libfoo.so.2".  None of the
>> > > > existing binaries using foo will be disturbed, but new programs can
be
>> > > > linked against the new ABI.
>> > >
>> > > I suppose these things are encoded into the library file? How?
>> >
>> > The details vary by platform.  Hence the insane libtool shell script.  In
>> > the case of linux, it is done by specifying "-Wl,-soname -Wl,libfoo.so.1"
>> > at the linking stage.
>> 
>> Oh, an ld flag. That's easy enough to add. It doesn't seem to vary by
>> platform, but by toolset, from the evidence above. In any case, there's no
>> reason we can't do that (and in fact you can get it to happen for any of
the
>> boost libraries without changes to the build system).
>
>OK, here's the modification I'd like to make for Debian's build.
>
>What can I put in the place of "LIBRARY_NAME" to get the name of the
>file being built --- something like $(1), but without the entire path.

Try $(<[1]:G=:D=).

>I also need the boost version string.  I am content to use
>-sBOOST_VERSION=1.27 on the jam invocation, but if there is already a
>variable that holds this value, I'd use it instead.

That seems fine. I also just added "BOOST_VERSION" to the top level Jamrules,
so it should be useable without specifying it in the command line.

>Index: tools/build/gcc-tools.jam
>===================================================================
>RCS file: /home/steve/lib/cvs/debian/boost/tools/build/gcc-tools.jam,v
>retrieving revision 1.1.1.2
>diff -u -b -B -r1.1.1.2 gcc-tools.jam
>--- tools/build/gcc-tools.jam  7 Feb 2002 15:34:18 -0000   1.1.1.2
>+++ tools/build/gcc-tools.jam  2 Mar 2002 20:27:44 -0000
>@@ -97,7 +97,7 @@
> # for gcc, we repeat all libraries so that dependencies are always resolved
> actions gcc-Link-action bind NEEDLIBS
> {
>-    $(GCC_BIN_DIRECTORY)g++ $(IMPLIB_COMMAND)$(<[2]) $(LINKFLAGS) -o
"$(<[1])" 
>-L$(LIBPATH:T) -L$(STDLIBPATH:T) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)"
-l$(FINDLIBS) 
>-Wl,-rpath-link,.
>+    $(GCC_BIN_DIRECTORY)g++ $(IMPLIB_COMMAND)$(<[2]) $(LINKFLAGS) -o
"$(<[1])" 
>-L$(LIBPATH:T) -L$(STDLIBPATH:T) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)"
-l$(FINDLIBS) 
>-Wl,-rpath-link,. -Wl,-soname,LIBRARY_NAME.BOOST_VERSION
> }
> 
> actions gcc-dllwrap bind NEEDLIBS

There is one problem with this solution... it will tag any library created
regardless of wether it's in Boost or not. If you happen to use the
Boost.Build system for something other than Boost, which I do, the above would
not be "a good thing".

The best way is to specify the above in the dll target spec itself with
<linkflags>, which is what Dave was refering to above. It might look like:

dll test : test.cpp
    : <gcc><linkflags>"-Wl,-soname -Wl,libtest.so.$(BOOST_VERSION)"
    : debug release ;

But even that seems somewhat cumbersome.

Would it seem reasonable to add a <dllversion> feature? And possibly a
<dllname> one also?

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