Re: gcc compiles assert() to code that requires linking with gcc

[Martin Buchholz <martin at xemacs dot org>]

>>>>> "AO" == Alexandre Oliva <aoliva@redhat.com> writes:

AO> On Jun 26, 2000, Martin Buchholz <martin@xemacs.org> wrote:
>> Think about what you're saying.  The policy of requiring libgcc for
>> the C linking stage is an *exclusionary* one.

AO> Why?  You can always have libgcc and link it with your programs, even
AO> when you're linking using a proprietary toolchain.

Library author A wants to create a portable library.  Writes it in C.
Distributes libFOO.1.0.0.tar.gz

Binary packager B works at MegaCorp.com and would like to make the
latest version of libFOO.a available to everyone working at MegaCorp.
Because B is secretly a free software zealot, B uses entirely free
software, including gcc, to create libFOO.a and places the updated copy
in /freeware/lib, which is NFS mounted by all computers at the
company.  B tests libFOO.a carefully using the usual toolbox of free
software.  B announces libFOO.a on a company-wide web site.

Later, complaints come in from all over MegaCorp that builds are
breaking.  For some reason, there's this unresolved symbol __eprintf
in libFOO.a.  Where did that come from?  Didn't anybody test the new
library?  Many users at MegaCorp, traditionally distrustful of free
software, use the vendor compiler, which "always just works".  They
trace the link failure back to libFOO.a and packager B.

B loses his job at MegaCorp and his devotion to free software.  The
developers of MegaCorp see what happens when you start playing with
free software.  The CIO of MegaCorp sends out a memo forbidding the
use of gcc.  B never goes on to become a future gcc developer.

That's why you want assert() not to depend on libgcc.

AO> Therefore, aiming at a libgcc-independent GCC is much more work than
AO> you might think.

I'd be happy with a GCC that creates libgcc-independent code for most
real-world libraries on most popular Unices, most prominently Solaris.
Far from being a lot of work, fixing assert() will cause most of the
problems to go away.

>> When compiling with -Omake-it-fast-not-portable, you can call the
>> external __eprintf from libgcc.

AO> __eprintf is the simplest of the problems.  You can always compile
AO> with -DNDEBUG to get rid of calls to it :-)

I am concerned not with my own build problems, but with the fate of my
friend B above...