Re: [boost] --layout=system creates versioned libraries

From: Julio M. Merino Vidal (jmmv84_at_[hidden])
Date: 2005-06-18 03:41:37

On Fri, 2005-06-17 at 21:03 -0400, Caleb Epstein wrote:
> On 6/17/05, Julio M. Merino Vidal <jmmv84_at_[hidden]> wrote:
> > Everything went correctly, but then I found more files than expected
> > under the stage/lib directory.  These are:
> > 
> > libboost_filesystem-mt.a
> > libboost-filesystem-mt.so (link to libboost_filesystem_mt.so.1.32.0)
> > libboost_filesystem_mt.so.1.32.0
> > 
> > As I understand from the documentation, setting --layout=system during
> > the build should cause all libraries to be unversioned (i.e., only the
> > .a and .so should be there), although from the above results it seems to
> > be working incorrectly in this platform.
> 
> No, I believe this is the correct behavior.  Versioned shared
> libraries (if used properly) ensure that you can't accidentally pick
> up an incompatible (older or newer) version of a library at run time,
> even if it has the same name as the one you compiled with.
> 
> As a user, you don't need to know you're linking with the .so.1.32.0
> version of the library, you just link with -lboost_filesystem-mt, and
> your linker takes care of the version binding.

The problem is that, as a packager, I need to know which files are being
created.  And to make things simple, they should be the same on all OSes
supported by the packaging system I'm working on (pkgsrc).

> The default --layout behavior adds the Boost version number into the
> actual library name (the part *before* .a or .so), which means you
> need to link with (say) -lboost_filesystem-gcc-mt-1_32.
> 
> > However, trying this same thing under NetBSD/i386 (GCC 3.3.3) resulted
> > in the expected files; the .so.1.32.0 was not created, and the .so one
> > was a real file, not a link.
> 
> Perhaps NetBSD doesn't support versioned shared libraries, or the
> Boost.Build plumbing doesn't know how to create them on that platform.

It does support versioned shared libraries.  Unfortunately, something
seems broken in this case.  Will keep investigating, now that I know
that the incorrect thing happens under NetBSD, not Linux.

Thanks!

-- 
Julio M. Merino Vidal <jmmv84_at_[hidden]>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/