Re: [boost] building shared boost libraries

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-13 18:52:22

----- Original Message -----
From: "Steve M. Robbins" <steven.robbins_at_[hidden]>

> OK.  So right now, I just run "jam" and see what gets built.  Is that
> the recommended way to determine if the library has a ".a" or ".so" file?

There /is/ no "THE recommended way". If you're asking for my recommendation,
I'd look at the documentation for the library, and its associated Makefiles
and Jamfiles.

> Or is there a document somewhere that lists them all?

I don't think so. We probably ought to add that to
http://www.boost.org/tools/build eh?

> Yes, I was.  I had assumed that they would be on the boost list.
> Bad assumption?

Jeremy's travelling right now, and Rich Lee isn't quite as active. Anyway,
neither of them is likely to notice a post with this title, IMO. I'd suggest
posting something with BGL in the title, and cc:'ing Lie-Quan "Rich" Lee
about it.

> Ah.  Now I see them in boost-base.jam.  Rule "Link-EXE" calls
>
>   Link-action $(<) : $(>) : EXE ;
>
> and rule "Link-DLL" calls
>
>   Link-action $(<) : $(>) : DLL ;
>
> So your suggestion is that, now that the two execution paths for
> linking got merged into one, that they should split again in
> Link-action?

I'm not really recommending it, but you seem to have an (aesthetic?)
objection to the way it works now, so if you want to do that, you can.

> Why wouldn't I just reimplement Link-DLL itself?

Because it does important stuff that you'd have to repeat.

> "SONAME" expands to "Shared Object NAME".  Think of it as the label for
> the application binary interface implemented by a shared library.
>
> For example, libfoo.so.1.0.1 might have a SONAME of "libfoo.so.1".
>
> Suppose a new "foo" library is released that fixes bugs, but does NOT
> change the ABI.  The new library could live in a file named
> "libfoo.so.1.0.2", with the same SONAME "libfoo.so.1".  All the
> existing binaries linked with the "libfoo.so.1" ABI will transparently
> start to use the updated library.

Only, I suppose, if it's put in the right place or the LD_LIBRARY_PATH is
appropriately updated?

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

> What I have described is basically the scheme that linux uses.  Other
> unix systems have a fancier scheme that allows you to specify a range
> of ABIs supported by a given library object.  The details vary widely
> and wildly across various platforms.  To my knowledge, the only tool
> that attempts to abstract the various versioning mechanisms is "libtool".
> See http://www.gnu.org/software/libtool/manual.html#Versioning for a
> discussion of libtool's model of library versioning.

I've poked into libtool docs before. It doesn't /look/ too complicated to
support versioning.

> I gather from the list archives that the auto-* tools were considered
> but discarded long ago.  I guess that jam is going to have to be
> taught all the things that libtool knows about building shared libraries.

How hard can that be (he says glibly about a 5000-line shell script)?
Seriously, though: how many details /are/ there to get right? As arcane as
jam code can be, it's lots more expressive than shell script. I think it
should be possible to duplicate this logic in far less code.

> I'm going to have a look to see if I can just re-use
> the old debian packaging with these old Makefiles.
> That may be the best short-term solution for debian.

You won't get a Boost.Python shared lib that way :(

If you can describe a bit more about what has to happen to get SONAMES
encoded (at a low level, i.e. on the command-line), I can probably get
Boost.Build to do something reasonable.

-Dave