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

[Martin Buchholz <martin at xemacs dot org>]

>>>>> "AO" == Alexandre Oliva <aoliva@redhat.com> writes:

AO> On Jun 26, 2000, Martin Buchholz <martin@xemacs.org> wrote:
>>>>>>> "AO" == Alexandre Oliva <aoliva@redhat.com> writes:
AO> On Jun 26, 2000, Martin Buchholz <martin@xemacs.org> wrote:

AO> Why?  You can always have libgcc and link it with your programs, even
AO> when you're linking using a proprietary toolchain.

>> Binary packager B works at MegaCorp.com and would like to make the
>> latest version of libFOO.a available to everyone working at MegaCorp.

AO> He'd have all his problems solved if he had created libFOO.so
AO> instead.  But let's save this for another thread :-)  I see your point.

If B had created libFOO.so, B would have been fired for a different
reason - the users' apps would have failed at run time, not link time!

(think "cc -l FOO -L /freeware/lib ...")

(But yes, please let's do this thread some other day)

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

AO> Again, assert() is not the only issue.  People have already pointed
AO> out how to get rid of this problem, and you're welcome to post the
AO> patches necessary to make it happen.  However, as others have also
AO> pointed out, uses of `long long' and FP-emulation functions will
AO> require libgcc as well.  And even though FP-emulation functions are
AO> not necessary for the platforms MegaCorp.com uses, libFOO's configure
AO> script has probably detected that GCC supports `long long' and used it
AO> all over, which means that B's libFOO would still require symbols from
AO> libgcc.

AO> B could avoid all the trouble, including that of being fired, by
AO> extracting the needed symbols from libgcc and adding them to his
AO> version of libFOO.a.  Or, he could recommend people to use GCC to link
AO> with libFOO.a, otherwise they'd have to explicitly link with libgcc.a,
AO> because the native compiler other employees use is too dumb to support
AO> certain features (or so he could phrase it :-)

AO> Unfortunately, there's no good replacement for knowledge/awareness.

This is guru-level knowledge.  The standard complaint about Linux is
you have to be a full-time hacker to be able to use it.  I *am* a
full-time hacker, but I still shot myself in the foot with gcc's
help.  Fortunately, in my case, the unportable binary libraries never
caused problems for anyone but me, and I was able to fix them (by
switching to the native compiler!).

>> I'd be happy with a GCC that creates libgcc-independent code for most
>> real-world libraries on most popular Unices, most prominently Solaris.

AO> Maybe we could have some switch to disable, or at least to warn, when
AO> using features that would require libgcc.  This might have saved B's
AO> job, but only if he knew about this flag.

He wouldn't have.

I think we can fix gcc instead.