Bug 12969 - [3.3.2 regression] Including sys/byteorder.h breaks configure checks
[3.3.2 regression] Including sys/byteorder.h breaks configure checks
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: other
3.3.2
: P2 critical
: 3.3.3
Assigned To: Eric Botcazou
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-08 22:11 UTC by Philip K. Warren
Modified: 2003-12-04 07:00 UTC (History)
4 users (show)

See Also:
Host: sparc-sun-solaris2.9
Target: sparc-sun-solaris2.9
Build: sparc-sun-solaris2.9
Known to work:
Known to fail:
Last reconfirmed: 2003-11-08 22:33:59


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philip K. Warren 2003-11-08 22:11:01 UTC
In gcc 3.3.2, the following change was made from gcc 3.3.1:

diff -ru gcc-3.3.1/gcc/fixinc/inclhack.def gcc-3.3.2/gcc/fixinc/inclhack.def
--- gcc-3.3.1/gcc/fixinc/inclhack.def   Wed Jul  2 01:47:05 2003
+++ gcc-3.3.2/gcc/fixinc/inclhack.def   Tue Oct 14 06:42:40 2003
@@ -297,19 +297,10 @@

 /*
  *  Completely replace <sys/byteorder.h>; with a file that implements gcc's
- *  optimized byteswapping.  Restricted to "SVR4" machines until either
- *  it is shown to be safe to replace this file always, or we get bolder ;-)
+ *  optimized byteswapping.
  */
 fix = {
     hackname = AAB_svr4_replace_byteorder;
-#ifndef SVR5
-    mach = "*-*-sysv4*";
-    mach = "i[34567]86-*-sysv5*";
-    mach = "i[34567]86-*-udk*";
-    mach = "i[34567]86-*-solaris2.[0-4]";
-    mach = "powerpcle-*-solaris2.[0-4]";
-    mach = "sparc-*-solaris2.[0-4]";
-#endif /* SVR5 */
     files    = sys/byteorder.h;
     replace  = '#ifndef _SYS_BYTEORDER_H
 \#define _SYS_BYTEORDER_H

so a new sys/byteorder.h is now generated by fixincludes. However, several
configure checks for common software, like openssh, use the c preprocessor to
determine if a header file exists. If you run the c-preprocessor on the
following file in gcc 3.3.1, you get:

pkw@hedwig:~$ cpp --version
cpp (GCC) 3.3.1
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

pkw@hedwig:~$ echo "#include <netdb.h>" > test.c
pkw@hedwig:~$ cpp test.c > /dev/null
pkw@hedwig:~$ echo $?
0

With gcc 3.3.2, you get:

pkw@hedwig:~$ /opt/csw/gcc3/bin/cpp --version
cpp (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

pkw@hedwig:~$ echo "#include <netdb.h>" > test.c
pkw@hedwig:~$ /opt/csw/gcc3/bin/cpp test.c > /dev/null
In file included from /usr/include/netinet/in.h:48,
                 from /usr/include/netdb.h:98,
                 from test.c:1:
/opt/csw/gcc3/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/include/sys/byteorder.h:26:2:
#error You lose! This file is only useful with GNU compilers.
pkw@hedwig:~$ echo $?
1
Comment 1 Andrew Pinski 2003-11-08 22:33:57 UTC
This was cause by (but was only applied to the 3.3 branch):
2003-08-11  Kean Johnston  <jkj@sco.com>

        * fixinc/inclhack.def (sco_math): Updated test text and select trigger
        according to bkorb's review.
        * fixinc/inclhack.def (sco_regset): Ditto.
        * fixinc/inclhack.def (AAB_svr4_replace_byteorder): Remove all mach
        lines so that this file is unconditionally replaced.
A different patch was applied to the mainline:
2003-08-24  Nathanael Nerode  <neroden@gcc.gnu.org>

        * fixinc/inclhack.def (AAB_svr4_replace_byteorder):  Enhance
        comment.  Enable for DYNIX/ptx systems (when they switch to
        regular fixincludes).
        * fixinc/fixincl.x: Regenerate.

Can someone fix this problem?
Comment 2 Nathanael C. Nerode 2003-11-09 18:25:41 UTC
My patch was of course correct.  :-)

The question of whether to enable byteorder.h replacement on *all* systems as
opposed to a select list is interesting.  However, the discussion does not
clearly conclude that it's a good idea.  Accordingly, I think that was a
mistaken change.  The "#ifndef SVR5" lines are unnecessary and bogus, of course
(note that SVR5 is undefined by default).  I suggest that 3.3-branch be reverted
to the state before this most recent patch (where there is still a list of
machines); meanwhile mainline should simply have the #ifndef SVR5 / #endif lines
removed, retaining the list of machines.

The fixes to sco_math and sco_regset belong on mainline, and were not put there.
 Kean, please put them there.  :-)  (*Don't* copy any other 3.3-branch changes
to mainline, these are the only two which are missing and belong there.)
Comment 3 Eric Botcazou 2003-12-01 09:14:29 UTC
As per Nathanael suggestion, I'll revert the faulty patch on the 3.3 branch on
12/08 if no progress is made before that date.
Comment 4 CVS Commits 2003-12-03 20:10:47 UTC
Subject: Bug 12969

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	jkj@gcc.gnu.org	2003-12-03 20:10:44

Modified files:
	gcc            : ChangeLog 
	gcc/fixinc     : inclhack.def fixincl.x 
	gcc/fixinc/tests/base/ansi: string.h 

Log message:
	2003-12-03  Kean Johnston  <jkj@sco.com>
	
	PR 12969
	* fixinc/inclhack.def (AAB_svr4_replace_byteorder): Revert the
	change I made on 2003-08-11 that removes the mach lines.
	Restore them to the same list thats in the head, as per
	Nathanael Nerode's changes.
	* fixinc/fixincl.x: Regenerated
	* fixinc/tests/base/ansi/string.h: Fix test case

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.820&r2=1.16114.2.821
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/inclhack.def.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.139.4.15&r2=1.139.4.16
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/fixincl.x.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.132.4.14&r2=1.132.4.15
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/tests/base/ansi/string.h.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.1.2.2&r2=1.1.2.3

Comment 5 Kean Johnston 2003-12-03 20:11:04 UTC
I just checked in the fix for this that Nate suggested. Sorry it took so long.
Comment 6 Eric Botcazou 2003-12-04 07:00:07 UTC
Many thanks Kean!