Boost logo

Boost :

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 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, might have a SONAME of "".
> 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
> "", with the same SONAME "". All the
> existing binaries linked with the "" 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 "", with a SONAME of "". 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 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at