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

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

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

I don't know. I guess a statement by a maintainer would be as official
as it could get - I suggest you directly contact the maintainer from
whom you'd accept a policy statement as official.

> 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).

Proprietary Unix system vendors do have such policies. However, they
have the freedom to put functions used by their compilers into the C
library; GCC cannot modify the system's C library and thus provides
supporting functions in a different library. This library essentially
becomes part of the system. Just as you need to link the C library if
you have code compiled with the system vendor's compiler, you need to
link libgcc if you have code compiled with gcc. Furthermore, you also
need to link crtbegin.o and crtend.o, in a number of cases, or
initializers won't work.

In case you don't believe me, here's a list of symbols in libc.so.1 of
Solaris 2.6:

000a8688 ? .div
0001d29c t .div_sw
000a864c ? .mul
0001d554 t .mul_sw
000a86dc ? .rem
0001d78c t .rem_sw
0001d0d0 T .stret1
0001d108 T .stret2
0001d140 T .stret4
0001d140 T .stret8
000a86bc ? .udiv
0001d290 t .udiv_sw
000a866c ? .umul
0001da44 t .umul_sw
000a8714 ? .urem
0001d780 t .urem_sw
0003a844 T __assert

Likewise, assert is defined as

#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0))

> GCC in this case would have a
> *more* exclusionary policy than the very organizations usually accused
> of such practices.

Well, these organizations are not primarily accused of defining
non-standard functions, but of not sharing the source code of these
functions - this is what makes the functions proprietary and non-free.

> 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.

Just put "long long" operations into your code on a system which does
not natively support them (e.g. on a standard Solaris installation).

Regards,
Martin