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:

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

MvL> I don't know. I guess a statement by a maintainer would be as official
MvL> as it could get - I suggest you directly contact the maintainer from
MvL> 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).

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

You are correct that gcc has more implementation difficulties than the
vendor compiler, since the vendor compiler can strongly influence the
contents of the vendor libc.  However, that is an implementation
detail that the user shouldn't really care about.  The principle that
both compilers should try to create binary-portable libraries stands.

Note that the vendor compiler could have chosen to put its special
symbols like __assert into a library shipped with the compiler, as gcc
does.  If they had done that, gcc would have had to provide its own
implementation of __assert.  By placing __assert into libc, they
essentially made __assert part of that platform.  They could not
remove it, for binary compatibility with their own legacy applications.

When configured for Solaris 2.6, both the vendor compiler and gcc can
take the presence and contents of libc for granted, at least in
today's software environment (glibc for Solaris is not really an option).

...

MvL> 0003a844 T __assert

MvL> Likewise, assert is defined as

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

It would be reasonable for gcc (on Solaris only, of course) to have
the exact same definition for assert, since libc's __assert is part of
the platform (speaking binary-ly).  For complete portability (for a
future glibc on Solaris, perhaps), also implement an __assert for
Solaris only in libgcc to remove the dependency on libc.  It ought to
be trivial to implement, perhaps using __eprintf.

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

MvL> Well, these organizations are not primarily accused of defining
MvL> non-standard functions, but of not sharing the source code of these
MvL> 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.

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

But portable software doesn't use long long, as least not without a
configure check.  Probably, general purpose libraries that try to
maintain binary portability should avoid long long, even when
configured with a compiler that provides it.