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

[Martin Buchholz <martin at xemacs dot org>]

>>>>> Eons ago, "Mark" == Mark Mitchell <mark@codesourcery.com> wrote:

>>>>> "Martin" == Martin Buchholz <martin@xemacs.org> writes:
Martin> Could we have an "official" policy statement from the GCC
Martin> development team on this?

Mark> I am a member of the GCC Steering Committee, but I cannot speak for
Mark> the SC as whole.  Thus, my statements count for something, but they're
Mark> by no means the final word.

Mark> There are two issues here:

Mark>   - Should GCC compiled libraries have, under any circumstances,
Mark>     dependencies on libgcc?

Mark>   - Should using `assert' result in a dependency on libgcc?

Mark> The answer to the first question is definitely yes.  For example, GCC
Mark> uses libgcc to provide floating point emulation for processors that do
Mark> not support floating point.  GCC uses libgcc to provide support for
Mark> exception-handling and global initialization in C++ and Java, as
Mark> appropriate.

Mark> However, the fewer dependencies on libgcc the better, all things being
Mark> equal.  If you can implement assert in a way that is not detrimental
Mark> in other ways, but does provide the benefit that simply using `assert'
Mark> does not pull in libgcc, that sounds fine to me.  You still should not
Mark> depend on being able to avoid linking in libgcc; it may well be needed
Mark> for other purposes.

Mark> You mention the practices of other compiler vendors.  Many compiler
Mark> vendors include functionality equivalent to libgcc in the OS C
Mark> library.  GCC cannot do that, in general, since the GCC developers
Mark> have no control over the OS C library.  So, a separate library is used
Mark> instead.

You would be surprised how little control the compiler group at a
company like Sun has over the libc that ships with the vendor's own
OS.  

Firstly, the two groups are often politically at war (remember that
Sun's compiler was a Sun `planet' for a while, that was later de-planetized).

Secondly, and more signicantly, the problem of binary compatibility
(commercial Unix vendors usually care more about binary compatibility
than the average gcc developer) means that compiler generated code has
to work with 10-year old libc's.  This effectively removes the
possiblity of the compiler generating code that calls a new function,
because hardly anyone has 10 years of patience to wait for the
function to appear in everyone's libc.  The result is that the Sun
compiler has effectively no "inside" advantage compared to gcc.  The
functions in libc are specified in the various ABI's (in this
particular case, you can thank Sun for being so "open"), and the
compiler developers must write code to that ABI.  End of story.  If
gcc also wishes to be binary compatible, it too must write to the
ABIs.  This might mean that you have assert written to call __assert()
on some platforms, and __eprintf() on others, purely for reasons of
binary compatibility.

Mark> In short, when you imply that the output of most compilers works
Mark> without linking in a special library, you're incorrect; it's just that
Mark> the library you must link in is the C library, which you probably
Mark> wanted to link in anyhow.

I believe my argument above refutes your argument in the previous paragraph.

Sun's cc writes to a portable binary API, and gcc "cheats" by writing
code that depends on libgcc.

gcc (and the free software movement in general) should embrace binary
compatibility more.  That means complying with ABIs.

In fact, the whole problem you are currently having with shared/static
libgcc is related to the problem of not complying with ABIs or perhaps
in the Linux world, of not even having any.  

These comments are only for C - I don't understand C++ enough to know
whether binary compatibility there is at all practical.

Thanks for caring.

Martin