From: Steve M. Robbins (steven.robbins_at_[hidden])
Date: 2002-01-13 18:10:36
On Sun, Jan 13, 2002 at 04:55:37PM -0500, David Abrahams wrote:
> Whether any library is built as static or shared is up to its designer. I
> think Bill Kempf has good reasons not to build threads as a shared lib, but
> I'm not sure of that.
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?
Or is there a document somewhere that lists them all?
> > There is a Jamfile in libs/graph/build, but the graph project is not
> > a subinclude of the top-level Jamfile. Intentional or oversight?
> You'll have to ask the BGL guys. Oh, maybe you are trying to ask them.
Yes, I was. I had assumed that they would be on the boost list.
> > The shared library file for regex lacks a SONAME. I poked around in
> > the jam stuff to fix this. It appears that jam (or boost?) shares the
> > same "Link-action" rule for both programs and shared libraries. Surely
> > there ought to be different rules for building a program versus building
> > a shared object?
> That's up to the toolset. Often the build actions are similar enough that
> it's best to use a single build action with different variable settings. The
> third argument to Link-action is the target type (EXE, DLL, or PYD). You can
> write the Link-action rule to dispatch to different rules if you like.
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
Why wouldn't I just reimplement Link-DLL itself?
> > Is there any BOOST policy on library versioning and SONAMES? I'm
> > building packages for Debian. The last packages that were built for
> > Debian were based on BOOST 1.21, and they did appear to use SONAMES.
> Sorry, I'm a bit ignorant. Can you explain what SONAMES are supposed to do?
"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.
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.
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 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.
> > However, all that mechanism (e.g. the makefiles) appears to have been
> > purged in the move to JAM. True?
> In most cases there are still Makefiles lying around.
Err, yeah. I had forgotten to look for files named '*.mak'
when I wrote that.
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.
-- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk