On Wed, Mar 12, 2008 at 09:11:25PM -0400, David Abrahams wrote:
on Sat Feb 23 2008, "Steve M. Robbins" <steve-AT-sumost.ca> wrote:
[...]
This produces pairs of library files such as
bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a
(and similar pairs for shared libraries and all other variants).
The key item to note is that the two files have the same name. The python version, unlike the GCC version, is not embedded in the library name. So these files cannot both be installed into /usr/lib.
I don't know how such name gristing is generated in Boost.Build, but IMO we should change the naming to account for the Python version.
Perhaps. For the moment, I can get the desired effect using --buildid.
The question, then, is how to distinguish them once installed? Should we:
1. Rename the resulting libraries to decorate them with the python version in addition to the gcc version? This could generate
libboost_python-py24-gcc42-1_34_1.a libboost_python-py25-gcc42-1_34_1.a
I'm not an expert in this area, but it's been my understanding that simply renaming library files doesn't work for some reason.
Partly true. I believe you can rename the static libs (.a files) at will. The problem lies in the shared libs. Subsequent to writing the above, I discovered that the two shared libraries (.so.*) have exactly the same SONAME, so renaming doesn't work for them.
2. Similar to above, but use bjam's --buildid option? This has the drawback that the build ID shows up differently than the GCC version decoration, e.g.
libboost_python-gcc42-1_34_1-py24.a libboost_python-gcc42-1_34_1-py25.a
Sounds more likely to work, even though it's ugly.
Yes, this works because the --buildid is incorporated into the SONAMEs, thus distinguishing them. Using --buildid is therefore the *only* solution short of hacking the soname generation myself.
I'd appreciate your thoughts. Have I overlooked a better solution? What are the other packagers of Boost.Python doing?
Unfortunately, we don't tend to get a lot of interaction with packagers around here, so we don't tend to know what they're doing. I think Boost raises more packaging issues than most other libraries, so it would be good to have more involvement from y'all.
Actually, the only thing about Boost that causes grief to packagers is that the toolset name (e.g. "gcc42") is embedded in the library filename. I just wrote a response on Boost.Build outlining this in some detail [1]. Embedding the compiler version requires Debian to rebuild all the boost packages each time a compiler change is made. This is unnecessary when the compiler ABI is maintained (e.g 4.1 -> 4.2) and also unnecessary when the ABI is broken, as Debian has another mechanism to handle that. Note that rebuilding the boost packages has a huge ripple effect, so it is more than simply "unnecessary", it is a very large headache. The fact that Boost embeds the Boost version in the library name is cause for grief to client software authors. But this is unavoidable as long as Boost doesn't take care to maintain ABI across versions. Fortunately, there is a simple solution to this, which I touch on in my post [1]. Regards, -Steve [1] http://lists.boost.org/boost-build/2008/03/18565.php