This is the mail archive of the libc-hacker@cygnus.com mailing list for the glibc project.


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

glibc 2.1 and gcc 2.8



I understand that glibc 2.1 has been pulled from the official GNU
distribution site due to its refusal to compile with gcc 2.8, which
apparently violates GNU policy.  As the person who suggested this
refusal, I'd like to explain it a little.  There are valid technical
reasons why we chose to do this, and I'd hate to see an important
release be delayed any longer over politics.

C++ exception handling, as implemented by both gcc 2.8 and egcs,
relies on several functions which are provided by libgcc.a.  Those
functions have to be unique in the program plus all the shared
libraries it links.  We do that by pulling those functions into
libc.so and re-exporting them.

There are two different versions of exception handling, which
are mutually compatible provided that all the relevant functions are
present in libc.so.  When glibc is compiled by egcs, this happens.
When glibc is compiled by gcc 2.8, the functions needed for backward
compatibility are missing.  This causes binaries that use the old
exception handling mechanism to fail to run on a system where gcc 2.8
was used to compile libc.

The problem is not theoretical. In the libc 2.0 timeframe, it was at
one point impossible to use C++ programs compiled under Debian's Linux
distribution with Redhat.  We resolved the problem for 2.0 with a
gross hack.  We don't want to perpetuate the hack or risk another
failure of inter-distribution binary compatibility.  The simplest and
most reliable solution to the problem is to insist on the use of egcs
to compile libc 2.1.  Any version of egcs works.  Any compiler - egcs
or not, gcc or not - may be used to compile programs and shared
libraries that work with libc 2.1.

I'm aware of the reasons for the policy that all GNU software should
be compilable with gcc 2.8.  Those reasons are purely political and
should defer to technical concerns when they arise, as they have here.

zw


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