Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2003-07-08 08:35:23


This looks like a Boost.Build issue. Please consider taking it to the
jamboost list (see; I've
cross-posted this there.

 --=-=-= Content-Type: message/rfc822
Content-Disposition: inline

From: Ulrich Eckhardt <uli_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
Subject: reflect ABI in libname
Date: Sun, 6 Jul 2003 23:42:49 +0200
Lines: 90
Sender: boost-bounces_at_[hidden]
Approved: news_at_[hidden]
Message-ID: <200307062342.49615.uli_at_[hidden]>
Reply-To: Boost mailing list <boost_at_[hidden]>
X-Trace: 1057528281 6731 (6 Jul 2003 21:51:21
X-Complaints-To: usenet_at_[hidden]
NNTP-Posting-Date: Sun, 6 Jul 2003 21:51:21 +0000 (UTC)
Original-X-From: boost-bounces_at_[hidden] Sun Jul 06 23:51:19 2003
Return-path: <boost-bounces_at_[hidden]>
Original-Received: from ([])
by with esmtp (Exim 3.35 #1 (Debian))
id 19ZHPi-0001kA-00
for <gcp-boost_at_[hidden]>; Sun, 06 Jul 2003 23:51:18 +0200
Original-Received: from (localhost.localdomain
by (8.11.6/8.11.6) with ESMTP id h66Lkw425799;
Sun, 6 Jul 2003 16:46:58 -0500
Original-Received: from (
by (8.11.6/8.11.6) with ESMTP id h66LgQ425784
for <boost_at_[hidden]>; Sun, 6 Jul 2003 16:42:26 -0500
Original-Received: from uli by with local (Exim 3.35
(Debian))id 19ZHHV-0005FC-00
for <boost_at_[hidden]>; Sun, 06 Jul 2003 23:42:49 +0200
Original-To: Boost mailing list <boost_at_[hidden]>
User-Agent: KMail/1.5.2
X-BeenThere: boost_at_[hidden]
X-Mailman-Version: 2.1b3
Precedence: list
List-Help: <mailto:boost-request_at_[hidden]?subject=help>
List-Archive: <>
List-Unsubscribe: <>,
List-Subscribe: <>,
List-Post: <mailto:boost_at_[hidden]>
List-Id: Boost mailing list <>
Errors-To: boost-bounces_at_[hidden]
Xref: gmane.comp.lib.boost.devel:21847
MIME-Version: 1.0


The problem:
AFAIK, the two[1] libs built from boost always result in e.g. 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
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:
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"
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.

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 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.

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:


Dave Abrahams
Boost Consulting

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at