From: tgakem@pebbles.chem.tue.nl (Eric Meijer)
To: help-gcc@gnu.org
Subject: Re: Linking problems, mangling ?
Date: Thu, 16 Dec 1999 07:23:00 -0000 [thread overview]
Message-ID: <83avtd$9bj$1@news.tue.nl> (raw)
In-Reply-To: <83askq$dhu$1@news.stna.dgac.fr>
Roland TTK (hamon@timide.stna.dgac.fr.) wrote:
:
: Hi
: I have (succesfully ?) compiled my sources under solaris 2.6 with g++ 2.95 but
: I get undefined reference errors when linking. I try to link my object files
: with a library which was compiled by the sun C++ compiler.
You are trying to do something which cannot work.
: It seems like this
: compiler uses a specific mangling grammar, so the linker can't find the
: definitions it needs.
: I think the mangling grammar is pretty old (1994) so I can't beleive gcc
: doesn't emulate it.
You'd better believe it. Quote from the g++ faq:
------------------------------------------------------------------------
Why can't g++ code link with code from other C++ compilers?
"Why can't I link g++-compiled programs against libraries compiled by
some other C++ compiler?"
Some people think that, if only the FSF and Cygnus Support folks would
stop being stubborn and mangle names the same way that, say, cfront
does, then any g++-compiled program would link successfully against
any cfront-compiled library and vice versa. Name mangling is the least
of the problems. Compilers differ as to how objects are laid out, how
multiple inheritance is implemented, how virtual function calls are
handled, and so on, so if the name mangling were made the same, your
programs would link against libraries provided from other compilers
but then crash when run. For this reason, the ARM encourages compiler
writers to make their name mangling different from that of other
compilers for the same platform. Incompatible libraries are then
detected at link time, rather than at run time.
------------------------------------------------------------------------
This means that you need to compile all C++ source in an application
with one and the same compiler. With C libraries this problem generally
doesn't exist.
HTH,
Eric
--
E.L. Meijer (tgakem@pebbles.chem.tue.nl)
Eindhoven Univ. of Technology
Lab. for Catalysis and Inorg. Chem. (SKA)
WARNING: multiple messages have this Message-ID
From: tgakem@pebbles.chem.tue.nl (Eric Meijer)
To: help-gcc@gnu.org
Subject: Re: Linking problems, mangling ?
Date: Fri, 31 Dec 1999 22:24:00 -0000 [thread overview]
Message-ID: <83avtd$9bj$1@news.tue.nl> (raw)
Message-ID: <19991231222400.uyFKqLb3T_2RlxtOGYcWcUBqOYWKw0CfOPXWydmJQs4@z> (raw)
In-Reply-To: <83askq$dhu$1@news.stna.dgac.fr>
Roland TTK (hamon@timide.stna.dgac.fr.) wrote:
:
: Hi
: I have (succesfully ?) compiled my sources under solaris 2.6 with g++ 2.95 but
: I get undefined reference errors when linking. I try to link my object files
: with a library which was compiled by the sun C++ compiler.
You are trying to do something which cannot work.
: It seems like this
: compiler uses a specific mangling grammar, so the linker can't find the
: definitions it needs.
: I think the mangling grammar is pretty old (1994) so I can't beleive gcc
: doesn't emulate it.
You'd better believe it. Quote from the g++ faq:
------------------------------------------------------------------------
Why can't g++ code link with code from other C++ compilers?
"Why can't I link g++-compiled programs against libraries compiled by
some other C++ compiler?"
Some people think that, if only the FSF and Cygnus Support folks would
stop being stubborn and mangle names the same way that, say, cfront
does, then any g++-compiled program would link successfully against
any cfront-compiled library and vice versa. Name mangling is the least
of the problems. Compilers differ as to how objects are laid out, how
multiple inheritance is implemented, how virtual function calls are
handled, and so on, so if the name mangling were made the same, your
programs would link against libraries provided from other compilers
but then crash when run. For this reason, the ARM encourages compiler
writers to make their name mangling different from that of other
compilers for the same platform. Incompatible libraries are then
detected at link time, rather than at run time.
------------------------------------------------------------------------
This means that you need to compile all C++ source in an application
with one and the same compiler. With C libraries this problem generally
doesn't exist.
HTH,
Eric
--
E.L. Meijer (tgakem@pebbles.chem.tue.nl)
Eindhoven Univ. of Technology
Lab. for Catalysis and Inorg. Chem. (SKA)
next prev parent reply other threads:[~1999-12-16 7:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-12-16 6:36 Roland TTK
1999-12-16 7:23 ` Eric Meijer [this message]
1999-12-16 8:58 ` Roland TTK
1999-12-16 11:57 ` Dave Sieber
1999-12-31 22:24 ` Dave Sieber
1999-12-17 11:52 ` David C.
1999-12-31 22:24 ` David C.
1999-12-31 22:24 ` Roland TTK
1999-12-16 11:06 ` Mike Albaugh
1999-12-31 22:24 ` Mike Albaugh
1999-12-31 22:24 ` Eric Meijer
1999-12-31 22:24 ` Roland TTK
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='83avtd$9bj$1@news.tue.nl' \
--to=tgakem@pebbles.chem.tue.nl \
--cc=help-gcc@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).