Re: [3.0 critical] Make fixproto deal with assert.h (bootstrap fails)

[Mark Kettenis <kettenis at science dot uva dot nl>]

   Won't omitting it from libgcc.so still cause problems?

As things stand now, it probably won't.

   Maybe I'm missing something, but consider the following scenario:

	   1. user installs gcc 3.0;
	   2. user installs the binary distribution of the "foo" library
	      (libfoo.a), which was compiled with an earlier version of gcc;
	   3. user runs `gcc myfile.c -lfoo'.

Hmm, on systems that use GNU symbol versioning, backwards
compatibility of object modules (and therefore archives) is not
guaranteed.  And I think there are good reasons to discourage people
from distributing object modules for systems that provide a proper shared
library implementation.

   Won't the user get an error message about __eprintf undefined?

   Unless I'm mistaken, the link error will occur because

	   (a) the binary distribution of libfoo.a was built with an
	       older version of gcc, and hence uses the old GCC
	       definition of assert(), which references __eprintf();
	   (b) gcc will by default search only libgcc.so, not libgcc.a; and
	   (c) libgcc.so will not contain a definition of __eprintf().

Currently, unless you're specifying -shared or -shared-libgcc, GCC
will use libgcc.a instead of libgcc.so.  If you specify -shared you're
building a shared library, and the undefined reference to __eprintf
shouldn't be a problem.  If you specify -shared-libgcc, it's not too
unreasonable to expect that things aren't completely backwards
compatible.  And you could always specify libgcc.a yourself.

Mark