This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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.

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

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

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

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

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

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

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

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]