Undefined "_eprintf"

Undefined "_eprintf"

[Richard Kenner]

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 is this supposed to work?

Re: Undefined "_eprintf"

[Fergus Henderson]

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.

Re: Undefined "_eprintf"

[H . J . Lu]

On Mon, May 14, 2001 at 01:21:37AM +1000, Fergus Henderson wrote:
> 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.

Those kinds of things make me wonder how serious some gcc developers
think about maintaining a stable ABI for libgcc.

When I first port gcc to Linux more than 10 years ago, I had to use cc
from a commercial unix to compile libgcc1.a since gcc 1.3x couldn't
compile it. Many months/years later, I still kept libgcc1.a for Linux
even though gcc didn't need libgcc1.a anymore. Does anyone know why?
It is because I'd like to keep the binary compatibility for the old .o
files compiled with the ancient gcc. Admittedly, I doubt anyone still
uses that old .o files.


H.J.

Re: Undefined "_eprintf"

[Joe Buck]

Fergus Henderson writes:
> 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.

I second Fergus's request.