gcc 2.96: System headers get fixed inadvertently for i386-linux-gnu

Maciej W. Rozycki macro@ds2.pg.gda.pl
Wed Jun 14 07:42:00 GMT 2000

On Wed, 14 Jun 2000, Jeffrey A Law wrote:

> Every system, free or proprietary has had bug in its header files.  That is
> why we're moving to always running fixincludes.

 I see.  But why only i[34567]86-*-linux-gnu* got changed, then and not
all linux-gnu* (and a whole bunch of other systems, starting with
alpha*-dec-vms* -- did not).  They all still have "fixincludes=" (i.e. 

> Because glibc, like every other C library has had broken header files over
> time.  We are not going to force people to upgrade glibc because it has
> a broken header file when GCC can fix it.

 Hmm, working bugs around instead of fixing them is not in the spirit of
free software, IMHO.  I understand this may be the only (yet ugly) way for
proprietary systems, where convincing vendors to prepare fixes and then
provide them to customers without extra charges may be next to impossible. 

 There is also a practical issue here.  At present, one has to upgrade
glibc when it has a broken header file.  It's reasonable to upgrade
software to get rid of bugs, be it glibc, gcc or whatever.  With the new
style one has to assure both header trees are in sync.  This means
whenever one upgrades glibc (or in fact any library) or even patches any
header, he has to make sure to perform respective changes to gcc's private
tree.  I don't think we win anything by introducing this mess.  We surely
risk a great confusion, such as strange segfaults due to programs compiled
using different headers from ones glibc uses.  This may seldom be an issue
for proprietary systems, where the libc gets modified relatively rarely,
but glibc updates get released every few months and patches might get
applied even more frequently.  I do compile glibc several times between
releases due to various fixes, for example...

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

More information about the Gcc-patches mailing list