Shared publicly  - 
 
Packagers:

If you're packaging ICU on a Linux distribution, please add the "--disable-renaming" option to your configure line. Upstream recommends it.

And we users of ICU will thank you. Starting in 2013, we may be able to depend on ICU.

Hopefully someone will figure out a similar option for Boost and people will be able to use it.

EDIT: Turns out, it's only a partial solution. This stops the silly renaming of symbols, but the library's SONAME is still changed on every release.
1
1
Mikhail Zabaluev's profile photoThiago Macieira's profile photoDon Sanders's profile photoVladimir Prus's profile photo
15 comments
 
and it breaks various builds of icu users as well.
 
People should not be encouraged to use Boost for anything practical, so the soname stupidity is actually a good thing. ICU at least provides useful functionality that took Glib developers some months to replicate...
 
What option do you need for Boost? I can certainly implement whatever you want.
 
+Thiago Macieira, I am afraid that's not a build system options issue. Boost does not promise or keeps binary compatibility, and changing sonames in every version is just consequence of that unfortunate fact. Keeping binary compatibility was discussed on the mailing list, but seems like majority of developers just don't care.

Though, last time I checked, the only compiled Boost library that KDE required was program_options, and since that is rather stable, it may be possible to just fix it's soname. Not sure that's any help for general users.
 
Point taken. I assume making all of Boost header-only, as some radicals propose, won't make things any better? :-)
 
No. They need to keep binary compatibility in the data structures and in type names. If I have a function I export that takes a Boost type, said type must never change its mangled name. That includes changing namespaces and template parameters.
 
The public data types must never substantially change their member definitions, either. Boost people will never get this.
 
If the functions are all inline, changing the members is not a big deal, provided that no one is using PMFs as template parameters. Changing the functions' contents is less bad, remembering the policy: it must be ok for the old function to be executed.
 
If a data structure definition is used as part of the public API in more than one dynamic library/executable that can meet in one process, all those must be recompiled at the same time when the definition changes. Avoiding the ABI entanglement is possible, but this requires vigilance and makes such inlined types less useful than ABI-stable types properly backed by a shared library, such as Qt.
 
Data structure compatibility is basic compatibility requirement. It affects C libraries too. They're very easy to see. It gets hard as the type itself gets complex -- for example, can a given pointer be null or not? If previous versions of a library did not check for null before dereferencing it, then new versions can't set it to null, ever.

C++ adds complexity when it comes to virtual tables (rules are simple) and because mangled names of functions contain the names of the types that they accept. That's why renaming a type, by way of changing template parameters or by typedef to a different type, is binary incompatible.

Those who propose to use namespaces as versioning tools are deluded.
 
I think Boost is an excellent library.

I don't see why Qt couldn't use Boost internally, that is without exposing Boost APIs in the public Qt API. Utilized parts of Boost could be copied into 3rd party if necessary.

Having said that, I'm not sure how Qt would benefit from using Boost internally, and I don't see any problem with developers using Boost and Qt together in projects.
Add a comment...