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

[Martin Buchholz <martin at xemacs dot org>]

>>>>> "MvL" == Martin v Loewis <martin@loewis.home.cs.tu-berlin.de> writes:

>> I believe `assert' should be implemented without using libgcc.  After
>> all, the native compilers on two platforms do it right.  How would you
>> feel if the native compilers were modified so that vendor libraries
>> created by that compiler required linking with that compiler as well?

MvL> Thanks for your bug report. I believe the feature is by design; code
MvL> compiled by gcc in general relies on libgcc being linked e.g. for
MvL> emulating certain operations that are not available in machine code.
MvL> So compiling code without references to libgcc is not an objective in
MvL> GCC.

Could we have an "official" policy statement from the GCC development
team on this?

Think about what you're saying.  The policy of requiring libgcc for
the C linking stage is an *exclusionary* one.  If the proprietary Unix
system vendors had such a policy for their native compilers, you would
never have been able to have a gcc on these platforms (or at least not
without laborious reverse engineering).  GCC in this case would have a
*more* exclusionary policy than the very organizations usually accused
of such practices.

Of course, there are performance tradeoffs.  Inlining __eprintf or
including its object code with every .o file might significantly
increase code size.  But that is what optimization flags are for.  The
default behaviour should be to produce portable code, where possible.
When compiling with -Omake-it-fast-not-portable, you can call the
external __eprintf from libgcc.

MvL> That said, if you feel this needs to be changed, please submit your
MvL> patch to gcc-patches@gcc.gnu.org.

I believe binary compatibility of libraries is very important.  I may
work on such a patch, if it is likely to be accepted (assuming good
quality of my patch, of course).  Currently assert() is the only known
problem I have observed after having compiled several large C libraries.

Martin