GCC's <assert.h> and C99

Martin Buchholz martin@xemacs.org
Fri Sep 22 23:38:00 GMT 2000

>>>>> "MS" == Mike Stump <mrs@windriver.com> writes:

>> Date: Fri, 22 Sep 2000 09:31:14 +0900 (JST)
>> From: Martin Buchholz <martin@xemacs.org>
>> To: Kamil Iskra <kamil@wins.uva.nl>
>> Cc: gcc@gcc.gnu.org

>> Imagine if the authors of *other* compilers insisted on using their
>> compilers to link their object code.  You'd never be able to use gcc
>> on commercial Unix systems.

MS> ?  They do have libraries and files that they do require one to link
MS> with.  Yet, that doesn't mean that we can't link in those files.

? You mean files like libc.a, crt0.o ?

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

MS> Just as other systems have various support libraries and files that
MS> support their compiler, we have some files and libraries to support
MS> ours.  The situation is actually symmetric.

Not really.  Other compilers require things that are part of the
operating system, not part of the compiler.  FOO.a files should not
have any dependencies on things not explicitly mentioned by the user
on the link command line.

E.g. if you create libfoo.a like this

gcc foo.c bar.c -o libfoo.a -lfrob

then a user of libfoo.a (years later) is required to have a libfrob
around when linking libfoo.a into some application.  But requiring an
underdocumented libgcc is going too far.

MS> People are free to prelink and resolve those dependencies, if they
MS> wish.  If they should, and choose not to, that is their fault.  In
MS> this case, it would be B's fault for being incompetent, and yes,
MS> incompetent people like B should be fired, or at least re-educated.

You really like your software to be user-hostile, eh?

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

MS> :-) Well, no, not really.  It will just hack-around one example of a
MS> requirement the compiler has.  That requirement is that you expose
MS> libgcc.a to the linker in some fashion.  Failure to do that, is using
MS> the tools in a way that we don't intent.

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

MS> If you are concerned, help us re-educate him.

That's the wrong answer.  

But this is deeply philosophical, so let's end the direction this
thread is heading.

MS> One can include all those .o files from libgcc.a that have symbols
MS> that any of their .o files in their library depend upon, in they
MS> library.  When one builds a shared library, one can link two versions
MS> of it, one with libgcc.a and one with out, and advise people that are
MS> going to use other compilers to link to use the prelinked version, and
MS> those that will use gcc to link, can just use the normal version.

More information about the Gcc mailing list