Re: Undefined "_eprintf"

["H . J . Lu" <hjl at lucon dot org>]

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.