Re: [boost] building shared boost libraries

From: Lee Brown (lee_at_[hidden])
Date: 2002-01-13 19:21:52

On Sunday 13 January 2002 14:09, you wrote:
> Hello,
>
> On Fri, Jan 11, 2002 at 12:15:04PM -0500, David Abrahams wrote:
> > [...] one of the biggest reasons to use Jam is that we can avoid
> > making the build/test system a pile of scripts written in a dozen
> > different languages that no one person has the expertise to understand.
> > Too many GNU tools are like this; it makes them impenetrable and
> > hard-to-use.
>
> I can understand why folks have this view.  The GNU auto-* tools, in
> particular, have accreted a lot of layers of complexity over the
> years.
>
> I hope you appreciate, therefore, that someone steeped in the unix
> world, having years of experience using auto-* tools, can find JAM
> just as impenetrable on the first go.

It would be nice to have a Gnutools build version I think. It may be a 
bit of a pain (ok even a big pain) for the developer but library users are 
very used to the configure/make routine. Actually I like to use GnuTools. 

lee

>
> I'm using linux (Debian) and the 1.26.0 release of BOOST.
>
> I have been able to get jam built and running, and it builds several
> flavours of static libraries for the regex, thread, and python
> libraries.  For regex, I also end up with a shared library, but there
> is no shared lib for the other two.
>
> There is a Jamfile in libs/graph/build, but the graph project is not
> a subinclude of the top-level Jamfile.  Intentional or oversight?
>
> The lack of shared lib for the thread and python parts of boost is a
> question of someone getting around to writing the jam rules?  Or is it
> that they ought not to have one?
>
> 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?
>
> 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.
> However, all that mechanism (e.g. the makefiles) appears to have been
> purged in the move to JAM.  True?  Should I forget about packaging
> shared libs, and ship only the .a files?
>
> Thanks for any tips or pointers,
> -Steve