This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Undefined "_eprintf"
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Subject: Re: Undefined "_eprintf"
- From: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Date: Mon, 14 May 2001 01:21:37 +1000
- Cc: gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- References: <10105131451.AA11459@vlsi1.ultra.nyu.edu>
On 18-Jun-2037, Richard Kenner, GNU C Maintainer <kenner@vlsi1.ultra.nyu.edu> wrote:
> I know this has been discussed, but I just ran into it.
>
> I did a normal "make bootstrap" and the stage1 build of f/fini has that
> undefined symbol. I think it's coming in via an include of assert.h from
> the installed GCC, which was a few-week old top-of-tree.
How about reverting the part of the change which removed _eprintf from
libgcc.a?
The changes to not install assert.h are fine and good.
But removing _eprintf() from libgcc.a breaks gcc's C ABI.
Many people distribute libraries of object files built from C sources,
and compiled with gcc. Many of these libraries use assert().
If _eprintf() is removed from libgcc.a, then libraries compiled
with earlier versions of GNU C won't work with GCC 3.0.
Oh, I see this has also been discussed on gcc-patches.
I hope the above provides a convincing argument why _eprintf()
should be retained in libgcc.a. It's all very well to clean
up libgcc.a while changing the C++ ABI, but any such changes
should preserve the C ABI.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.