--layout=system creates versioned libraries
Hi all, I'm building Boost by hand under a Linux/powerpc system, GCC 3.3.5. I've started creating a bjam binary as usual (and as explained in the docs), and then tried: $ bjam --layout=system --builddir=/tmp/work --with-filesystem \ -sBUILD='<threading>multi release' stage 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. 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. Any idea about what can be causing this issue? Am I doing something wrong? Thanks, -- Julio M. Merino Vidal <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
On 6/17/05, Julio M. Merino Vidal <jmmv84@gmail.com> 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 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.
Any idea about what can be causing this issue? Am I doing something wrong?
No. I don't think so. -- Caleb Epstein caleb dot epstein at gmail dot com
On Fri, 2005-06-17 at 21:03 -0400, Caleb Epstein wrote:
On 6/17/05, Julio M. Merino Vidal <jmmv84@gmail.com> 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@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
Julio M. Merino Vidal wrote:
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's the later.
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.
In the boost-root/tools/build/v1/gcc-tools.jam file, current CVS state, around lines 163-188 there's a switch for specifying the needed options to get version SO names working. It's this way because SO names are a linker feature and the linker varies per platform and not per compiler. This bit of code would need to acquire a new case for NetBSD, or possibly *BSD, as there's already an OpenBSD case. Am I correct in guessing that the linker option for specifying the soname in NetBSD is the same as for OpenBSD? Namely "-soname [libname]". If it is I can just change the "OpenBSD" case to cover all "*BSD" cases. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On Sat, 2005-06-18 at 10:34 -0500, Rene Rivera wrote:
Julio M. Merino Vidal wrote:
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's the later.
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.
In the boost-root/tools/build/v1/gcc-tools.jam file, current CVS state, around lines 163-188 there's a switch for specifying the needed options to get version SO names working. It's this way because SO names are a linker feature and the linker varies per platform and not per compiler. This bit of code would need to acquire a new case for NetBSD, or possibly *BSD, as there's already an OpenBSD case.
Am I correct in guessing that the linker option for specifying the soname in NetBSD is the same as for OpenBSD? Namely "-soname [libname]". If it is I can just change the "OpenBSD" case to cover all "*BSD" cases.
Yes, you are right. You'd change it to cover all the BSDs. (FWIW, I already sent a fix in a new thread, before reading this mail...) Thanks, -- Julio M. Merino Vidal <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
On 6/18/05, Julio M. Merino Vidal <jmmv84@gmail.com> wrote:
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).
I don't think thats a reasonable expectation, particularly when dealing with system-specific entities like shared libraries. For example, on OSX the suffix for shared libraries is "dylib", not "so". On Cygwin (which behaves an awful lot like most *NIXes), you'll have "lib" *and* "dll" files. -- Caleb Epstein caleb dot epstein at gmail dot com
On Sat, 2005-06-18 at 14:55 -0400, Caleb Epstein wrote:
On 6/18/05, Julio M. Merino Vidal <jmmv84@gmail.com> wrote:
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).
I don't think thats a reasonable expectation, particularly when dealing with system-specific entities like shared libraries. For example, on OSX the suffix for shared libraries is "dylib", not "so". On Cygwin (which behaves an awful lot like most *NIXes), you'll have "lib" *and* "dll" files.
Hmm well... the packaging system (pkgsrc) already handles this internally. Basically, all I need to do is list which files will be installed using their .so names (and .a), and it will take care to DTRT on other systems (change them to dylib's where appropriate, etc.). The problem arises when the library _name_ changes, as it won't be able to find the files listed in the package. This is annoying at the very least, and makes the package a nightmare to maintain: it often causes regressions on some of the supported platforms (as I don't have the resources to try them all, for example). So... as --layout=system already removes the toolset string from the library names (among several other things), why doesn't it remove -mt and similar suffixes too?) -- Julio M. Merino Vidal <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
Julio M. Merino Vidal wrote:
So... as --layout=system already removes the toolset string from the library names (among several other things), why doesn't it remove -mt and similar suffixes too?)
Because then it would not be possible to select between single-threaded and multi-threaded versions of the same library. (repeat for the other options) Basically what --layout=system does is remove the tags that are redundant when using the system compiler. Of course if you only build one particular variant of the libraries then the extra tags might seem redundant. If that's the case a packager could decide to provide shorter names (as symlinks) to the desired variant. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera <grafik.list@redshift-software.com> writes:
Julio M. Merino Vidal wrote:
So... as --layout=system already removes the toolset string from the library names (among several other things), why doesn't it remove -mt and similar suffixes too?)
Because then it would not be possible to select between single-threaded and multi-threaded versions of the same library. (repeat for the other options) Basically what --layout=system does is remove the tags that are redundant when using the system compiler. Of course if you only build one particular variant of the libraries then the extra tags might seem redundant. If that's the case a packager could decide to provide shorter names (as symlinks) to the desired variant.
I'm a little confused as to why the tags show up in the first place when they're redundant. We do have a system for removing irrelevant build properties from subvariant paths. I guess if you don't have a consistent sequence of tags it gets hard to document what the library name is on a particular system? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
Julio M. Merino Vidal wrote:
So... as --layout=system already removes the toolset string from the library names (among several other things), why doesn't it remove -mt and similar suffixes too?)
Because then it would not be possible to select between single-threaded and multi-threaded versions of the same library. (repeat for the other options) Basically what --layout=system does is remove the tags that are redundant when using the system compiler. Of course if you only build one particular variant of the libraries then the extra tags might seem redundant. If that's the case a packager could decide to provide shorter names (as symlinks) to the desired variant.
I'm a little confused as to why the tags show up in the first place when they're redundant. We do have a system for removing irrelevant build properties from subvariant paths.
They aren't redundant from the point of view of the build variants. But they could be viewed as redundant if a user (packager in this case) builds only one variant, and hence only provides one variant in the package. So if the packager only includes the BB default variant then the tags don't show up.
I guess if you don't have a consistent sequence of tags it gets hard to document what the library name is on a particular system?
They are consistent :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
David Abrahams wrote:
I'm a little confused as to why the tags show up in the first place when they're redundant. We do have a system for removing irrelevant build properties from subvariant paths.
Oops, just realized that I answered your question incorrectly :-\ The redundant tags removed are for the toolset and toolset version used to build. They are usually redundant for a system packager because there is only one default/canonical compiler toolset in the system. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera <grafik.list@redshift-software.com> writes:
I guess if you don't have a consistent sequence of tags it gets hard to document what the library name is on a particular system?
They are consistent :-)
I meant, if we start leaving some out they will be inconsistent. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
Caleb Epstein -
David Abrahams -
Julio M. Merino Vidal -
Rene Rivera