Distributing C++ libraries and name mangling

8 views
Skip to first unread message

Lee Muraleedharan

unread,
May 12, 1998, 3:00:00 AM5/12/98
to

I am building a C++ library using compiler X. So all the calls to std
library would be mangled according to X's name mangling scheme. When a
user builds her application using compiler Y and links with my lib,
references in my lib to standard library symbols would be flagged as
undefined symbols.

What is is the solution to this? Distributing source is not an option.
If I ship my compiler's std library the user can then link with that too
to resolve the references, but then the program will have 2 std
libraries. Is combining C++ objects/libraries from more than one
compiler reliable?

The library is built on Unix (Solaris, HP-UX, DEC Unix) and on Win NT,
using SparcWorks CC, HP CC, DEC CC and Visual C++ respectively.

I would like to hear your experiences and any suggestions for solving
the above problem. Thanks


--
__________________________________________________________________
Lee Muraleedharan mailto:le...@spatialinfo.com
SPATIALinfo Pty Limited Phone : +61 2 9239 4610
Level 1, 101 Sussex St. Fax : +61 2 9261 3472
Sydney, Australia, NSW 2000 http://www.spatialinfo.com

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

John Lacey

unread,
May 13, 1998, 3:00:00 AM5/13/98
to

Lee Muraleedharan wrote:
>
> Is combining C++ objects/libraries from more than one
> compiler reliable?

No. It is not reliable, and indeed I have never seen it work. (It
has historically worked for Unix-based C compilers, but not for
Windows-based C compilers, for instance.) It is *not* a name
mangling issue, it is an issue of calling conventions, binary
layout of objects (implementation of virtual functions, using
vtables or other techniques), etc.

The only solutions I know of are requiring your clients to use
the same compiler, handing out source code, wrapping the
interface in C, or using a binary interface that both compilers
can use. In the latter case CORBA and COM suggest themselves,
although there is no reason the ABI (application binary
interface) needs to be language-independent such as these are.

Requiring the same compiler is probably the most common
technique. You could expand things someone by offering multiple
compilers. There aren't that many compilers that matter (two per
platform, perhaps, the vendor's own and either g++ or Borland C++
Builder).

The binary interfaces (of which C really is one, in this context)
all dramatically constrain the interface you can present to
clients, but they also provide new benefits. None of these three
require your clients to use C++ themselves, for instance.

John L

cc: Lee Muraleedharan

Robert O'Dowd

unread,
May 14, 1998, 3:00:00 AM5/14/98
to

Lee Muraleedharan wrote:
>
> I am building a C++ library using compiler X. So all the calls to std
> library would be mangled according to X's name mangling scheme. When a
> user builds her application using compiler Y and links with my lib,
> references in my lib to standard library symbols would be flagged as
> undefined symbols.
>
> What is is the solution to this? Distributing source is not an option.
> If I ship my compiler's std library the user can then link with that too
> to resolve the references, but then the program will have 2 std
> libraries. Is combining C++ objects/libraries from more than one
> compiler reliable?

Heck no!

The standard explicitly encourages the system whereby different
compilers use different name mangling schemes. The reason is
to avoid problems with functions assuming an object has a given
layout of data in memory when it really has something different.
Things like virtual function tables are also likely to have
different layouts for different compilers. Think about the
effect of calling a virtual function, which is essentially a
pointer to a function [oversimplification] and calling the thing
at a different address <shudder>.

>
> The library is built on Unix (Solaris, HP-UX, DEC Unix) and on Win NT,
> using SparcWorks CC, HP CC, DEC CC and Visual C++ respectively.
>
> I would like to hear your experiences and any suggestions for solving
> the above problem. Thanks
>

Suggestions follow.

1) Build your library using compiler Y (i.e. your users compiler).
If you wish to support multiple compilers, distribute a
library for each one. If you are using std functions, see if
each library can be created in a way that includes the relevant
function in your library (or, better, distribute the std library
for the compiler with your library if that is permitted by the
vendor).

2) Make a statement in your documentation "this library is only
compatible with compiler X version N".


-<Automagically included trailer>
Robert O'Dowd Ph +61 (8) 9553 3618
DSTO Bldg A51 Fax +61 (8) 9553 3577
HMAS Stirling Email:
robert...@dsto.defence.gov.au
Rockingham, Western Australia, 6958

Disclaimer: Opinions above are mine and may be worth what you paid for
them

Alexandre Oliva

unread,
May 14, 1998, 3:00:00 AM5/14/98
to

Lee Muraleedharan <le...@spatialinfo.com> writes:

> What is is the solution to this?

There's no guarantee or requirement that a library compiled with one
C++ compiler is compatible with another compiler.

> Distributing source is not an option.

It is the only one. Unless you want to define a C interface for your
library, using extern "C" linkage specifications.

--
Alexandre Oliva
mailto:ol...@dcc.unicamp.br mailto:aol...@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Steve Clamage

unread,
May 14, 1998, 3:00:00 AM5/14/98
to

In article 1...@netlab.cs.rpi.edu, Lee Muraleedharan

<le...@spatialinfo.com> writes:
>I am building a C++ library using compiler X. So all the calls to std
>library would be mangled according to X's name mangling scheme. When a
>user builds her application using compiler Y and links with my lib,
>references in my lib to standard library symbols would be flagged as
>undefined symbols.

>What is is the solution to this? Distributing source is not an option.

The reason name mangling is different on different C++ compilers is
because
the binary object files are incompatible (not the other way around).

It is common for different C compilers on the same platform to generate
code which is incompatible. The sizes or alignment of types may be
different, or the code sequences for calling and returning from
functions (args passed on the stack? in registers? does caller or
callee clean up the stack?) may be different. By "platform", I
mean the combination of computer and operating system.

C++ has many additional degrees of freedom. For example: how are virtual
function calls implemented? how are classes with multiple inheritance
laid out? how are pointers to members implemented?

With incompatible C compilers, you may find that the object files
link, but the program fails mysteriously at run time. With C++, compiler
writers use different name-mangling schemes to prevent the incompatible
object files from linking, so you get early warning that something
is wrong.

If you don't want to distribute library source, you must compile
the library separately with each combination of compiler and
platform you wish to support.

You might also consider "shrouded" source distribution.
"Shrouded" source code has been converted into an equivalent program
that is difficult for humans to understand. For example, all names
are converted to meaningless alphanumeric sequences, code is reformatted
to remove helpful whitespace, and so on. (You shroud the code only when
you are ready to ship it -- you can't maintain or debug the shrouded
code!)

---
Steve Clamage, stephen...@sun.com

John R MacMillan

unread,
May 14, 1998, 3:00:00 AM5/14/98
to

|... Is combining C++ objects/libraries from more than one
|compiler reliable?

In general, no. Name mangling is not the only issue, there's also
class layout, exception handling mechanism, function call and return
and so on, and possibly even things like size of basic data types.

I have seen some library vendors solve this by dictating what
compiler the user must use or offering a version for the most
popular compilers on the platform, and some by distributing source
(sometimes obfuscated; one can make C++ pretty unreadable if
one wants).
--
To reply by mail, please remove "mail." from my address -- but please
send e-mail or post, not both

Gary Beckmann

unread,
May 14, 1998, 3:00:00 AM5/14/98
to

>>>>> Robert O'Dowd writes:

Robert> Lee Muraleedharan wrote:
>>
>> I am building a C++ library using compiler X. So all the calls to std

>> ...


>> What is is the solution to this? Distributing source is not an option.

>> ...
Robert> Heck no!
Robert> The standard explicitly encourages the system whereby different
Robert> ...
Robert> 1) Build your library using compiler Y (i.e. your users compiler).
Robert> ...

In other words, increase your costs by having to buy compilers and
needing a complicated distribution scheme as well as rebuild and test
for each new version of compiler to make sure it hasn't changed.
Anger your customers by requiring them to buy the library for each
compiler (and probably each new version of compiler), otherwise you
won't recoup your costs.

The standard is not there for the library builder. Either you have to
sell the source code (Rogue Wave's solution) or do it in C and provide
the header files to it.

This has to be one of the major holes in the standard. I guess the
compiler writers/sellers had more representation on the committee.

--
----------------------------------------------------------------------
Gary Beckmann | e-mail: ga...@radionics.com
RADIONICS | or: beck...@world.std.com
22 Terry Ave. | telephone: (781)272-1233
Burlington, MA 01803 | fax: (781)238-0606
USA |
----------------------------------------------------------------------

Matt Seitz

unread,
May 15, 1998, 3:00:00 AM5/15/98
to

Gary Beckmann wrote in message <6jfe7u$5...@netlab.cs.rpi.edu>...


>>>>>> Robert O'Dowd writes:
>
> Robert> Lee Muraleedharan wrote:
> >>
> >> I am building a C++ library using compiler X. So all the calls to std
> >> ...
> >> What is is the solution to this? Distributing source is not an option.

>[...]The standard is not there for the library builder.
>[...]


>This has to be one of the major holes in the standard. I guess the
>compiler writers/sellers had more representation on the committee.


That's because C++ is primarily a language standard, not a linker standard.

It seems like it would be nice to have a standard for object and library
files, but I don't blame the comittee for not trying to create such a
standard. Trying to define a standard for object files seems far removed
from defining a standard for the language. Can you make such a standard
that is portable across all processers and operating systems? What about
linking modules from different languages? What about C++ systems that use
interpreters and not compilers?

Java seems to be just such an attempt to define both the language and the
object file format. We'll have to wait and see how successful it is in the
long run. There are other attempts out there to define standards for object
and library files, such as the Microsoft DLL standard, the COM/Active X
standard, the CORBA standard, etc. Perhaps one of those will be the
solution.

Steve Clamage

unread,
May 18, 1998, 3:00:00 AM5/18/98
to

Gary Beckmann <ga...@radionics.com> writes:

>needing a complicated distribution scheme as well as rebuild and test
>for each new version of compiler to make sure it hasn't changed.
>Anger your customers by requiring them to buy the library for each
>compiler (and probably each new version of compiler), otherwise you
>won't recoup your costs.

>The standard is not there for the library builder. Either you have to
>sell the source code (Rogue Wave's solution) or do it in C and provide
>the header files to it.

>This has to be one of the major holes in the standard. I guess the


>compiler writers/sellers had more representation on the committee.

The last statement is a canard frequently repeated by those
who know nothing about the C++ committee or how it works.

The facts are that implementors comprise less than 10% of the
committee, and about 20% of those who are eligible to vote. Even
if implementors voted as a bloc, which they don't, they could not
force the outcome of any issue. (The committee operates by
consensus in any event. If an issue does not have near-unanimous
support it is reworked until it does. A standard that offends
half the committee serves no purpose.)

The statement also presupposes that the committee is divided
into "implementors" and "users", another idea false-to-fact.
I've been on the committee since the first meeting, and I can't
remember a single issue which divided members along those lines.

Now for the technical issue: Can or should the C++ standard
mandate a particular implementation? The committee as a whole
(and I don't know of a single dissenter) decided from the
beginning not to attempt such a thing.

First, a major design goal of C++ was to specify a language
which is suitable for efficient implementation on a wide
variety of computers. C++ is used in cameras and in mainframes,
on computers with small and large word sizes and address spaces.
No one implementation (size of basic types, to pick just one
example) can be appropriate for both a camera and a mainframe.

How about specifying the implementation per computer? Most
popular computers support multiple operating systems with widely
differing characteristics. No one implementation of C++ would
match all operating systems on a given popular CPU, assuming
the committee knew about all that existed.

How about specifying the implementation per platform, where a
platform is the combination of CPU and OS? That is possible in
principle, but how can the C++ standard do that? What about
OS's that change over time? What about OS's that are released
after the standard is published? What about OS's that no one
on the committee knows in detail? The logistics are impossible.

The OS vendor can specify the implementation (the Application
Binary Interface) for languages. Indeed, most do for C. The
problem with an ABI for C++ is that the language hasn't been
stable enough. Major releases of any given C++ compiler have
always been incompatible with each other, usually because the
previous ABI was incapable of supporting the newer language
features. (To pick two examples, early C++ vtables could not
support multiple inheritance, and typical name-mangling schemes,
even recent ones, could not support namespaces plus templates.)

Now that we (almost) have a standard for C++, we can expect
to see published ABIs for operating systems. It will then be
in the self-interest of compiler vendors to support those
ABIs. At that point, binary compatibility of libraries will
be both possible and practical. But not until then.
--
Steve Clamage, stephen...@sun.com

jka...@otelo.ibmmail.com

unread,
May 19, 1998, 3:00:00 AM5/19/98
to

In article <6jpbur$c...@netlab.cs.rpi.edu>,

cla...@Eng.Sun.COM (Steve Clamage) wrote:
> >This has to be one of the major holes in the standard. I guess the
> >compiler writers/sellers had more representation on the committee.
>
> The last statement is a canard frequently repeated by those
> who know nothing about the C++ committee or how it works.
>
> The facts are that implementors comprise less than 10% of the
> committee, and about 20% of those who are eligible to vote. Even
> if implementors voted as a bloc, which they don't, they could not
> force the outcome of any issue. (The committee operates by
> consensus in any event. If an issue does not have near-unanimous
> support it is reworked until it does. A standard that offends
> half the committee serves no purpose.)

To complete what Steve is saying: I've had many conversations with
implementors from different companies, and in every case, one of the
major motivations of the implementor was to get a standard conform
to what HIS customers wanted. Only when an implementor felt that
something was impossible in a given environment (or under conditions
his customers would accept) was any implementation issue raised.
I can remember some long email exchanges with implementors (from Sun,
in particular) basically asking me what I, as a user, thought was
important.

--
James Kanze +33 (0)1 39 23 84 71 mailto: ka...@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jka...@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique oriente objet --
-- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading

Reply all
Reply to author
Forward
0 new messages