[boost] reflect ABI in libname

From: Ulrich Eckhardt (uli_at_[hidden])
Date: 2003-07-06 16:42:49

Greetings!

The problem:
-------------
AFAIK, the two[1] libs built from boost always result in e.g. 
libboost_thread.so. The problem is that currently no OS has support for 
embedding the required ABI[2] into the runtime-linker info, therefore it only 
knows a libray name. 
When it finds a library but that lib has a wrong ABI, it fails more or less 
early and with more or less meaningful error-messages.

The workarounds:
-----------------
1. not using more than one compiler on a system. This works on a few Unix-like 
platforms where a compiler is part of the system but even there, people 
sometimes want to install a different one for various reasons.
2. use static linking. Works, but we don't want static linking.
3. supply a path to the proper lib explicitly. This is already a pretty good 
solution, apart from the fact that there are no "default install paths for 
ABI XYZ".
4. encode the ABI in the library-name. This solution is e.g. used by STLport 
on win32: stlport_vc645.dll is STLport 4.5 compiled with VC6.

I'd like to have boost adopt version 4 of it. Note that apart from the ABI 
itself, we'd also have to encode the stdlibrary into the name because 
std::string from GCC has a different binary layout than the one from STLport.

The name would then be like this:
  <libname><version>_<ABI-tag>[_<stdlib-tag>].so
The stdlib would be optional because a) not every lib necessarily uses it b) 
when not given, the default one that comes with the compiler is assumed.

For the tags for compiler and stdlib, I'd start this list:

gcc2.95 - for GCC 2.95
gcc2.96 - for the evil thing known as "GCC 2.96" 
(http://gcc.gnu.org/gcc-2.96.html)
gcc3.2 - for GCC 3.0 - 3.2
gcc3.3 - for GCC 3.3
vc6 - MS visual C++ 6
vc7 - (anyone a clue if there is a version 7 or if that version was marketed 
as .Net ?)
stlp4.5 - STLport 4.5

which mostly describes what compilers I use.

Drawbacks:
-----------
There is no such thing as "this compiler's ABI". GCC 3.3 by default emits the 
GCC3.2-ABI unless told differently. VC7's compiler finally makes wchar_t a 
distinct type, at least if told so by a commandline switch. I'm sure other 
compilers have their own ways to achieve the same.

No, I don't have a solution to this and I don't think there is one. I fear 
someone will have to step up and say "for XYZ 3.14 the command-line switches 
have to be --ph00=4". There will be people that wont like that decision, but 
there wont be a way around it. In case enough good arguments speak for a 
change, the next version of boost might change to a different setting for the 
compiler. Else, above workarounds can still be applied.

One big advantage to me is that I can simply link an app against say 
libboostthread1.30_gcc3.2.so and, assuming I didn't mess it up, be sure it 
runs on another system with that lib. It also means that boost could 
theoretically distribute compiled versions of its libs. 

Options:
---------
People often like having a 'debug-version' around that usually includes some 
assertions and is not stripped. Adding that as info to the libname in a 
uniform fashion would also be nice (I'd just append a '_debug' or '_dbg').

Yes, I know that all this is not ideal. However, I believe that the resulting 
chaos is much smaller than it could be and better than the status quo. It 
also means that mistakes will be made, but I'm willing to make them. I have 
the hope that we can agree on a common ABI for most cases and the rest can 
still use other means. Not daring to make a mistake for lack of a perfect 
solution is the greater pain for me.

Ulrich Eckhardt

[1] threads and Python-bindings (and regex ?)
[2] Application Binary Interface. Different C++ compiler's objectcode can't be 
mixed since e.g. name-mangling or calling conventions are different.