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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
