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
> Or is there a document somewhere that lists them all?
I don't think so. We probably ought to add that to
> 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
> 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
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
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk