Re: [Boost-build] A number of issues with boost.build in 1.36.0

Subject: Re: [Boost-build] A number of issues with boost.build in 1.36.0
From: Philipp Thomas (pth_at_[hidden])
Date: 2008-10-30 14:12:25

* Vladimir Prus (ghost_at_[hidden]) [20081030 17:28]:

> Well, I hope boost.build is at least a little bit easier -- that C++ Build is
> vastly easier that GNU toolchain.

That may be so, it's just that I'm much more familiar with the GNU toolchain.

> OK. I'd actually think that MT should be always on, but I realize
> that if you have ST and MT, then it will be hard to guarantee
> backward compatibility.

I just thought about it some more and I am testing
<base> <threading> <runtime> .

With backwards compatibility I mean that if the library doesn't use symbol
versioning, changes in the ABI of a library *mandate* increasing the major
version of a library. Only under those conditions does the standard library
versioning on most *NIX variants work and as far as I have watched the boost
project, this hasn't been addressed. Therefore I must assume ABI
incompatibilities and therefore use sonames that ensures that the libraries
are not ABI ompatible.

If I assumed ABI backward compatibility, it would be a bit more work as then
soname != libname, i.e. I'd have to get the C++ build to use something like
libboost_whatever.so.1 for soname and libboost_whatever.so.1.36.0 for the
library name.
 
> Qt used to, in 3.* timeframe, but it's MT-only now.

I understand that decision. I guess I should just keep things as they are
and only supply MT libraries and a non-mt symlink for linking so other
package maintainers don't need to patch their package to adapt to the
changed naming.
 
> You can build both ST and MT versions of boost libraries by passing
> 
> 	threading=single threading=multi
> 
> on bjam command line.

After again digging into the configuration, I figured as much :)

Once again thanks a bunch, as with your help I can now build packages I'm
rather satisfi8ed with.

> Do you mean this is RPM only? Of .spec is not the RPM .spec?

No, it's not RPM only. AFAIK the OBS does also support debian packages it's
just that I haven't dealt with a project that does create debian packages so
I don't know how it works and what is necessary to do so.

Philipp