Re: c/3297: fixincludes (?) removes pthread types from types.h

Re: c/3297: fixincludes (?) removes pthread types from types.h

[Grant Gould]

The following reply was made to PR c/3297; it has been noted by GNATS.

From: Grant Gould <ggould@intouchsys.com>
To: Bruce Korb <bkorb@pacbell.net>, gildea@intouchsys.com,
   gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: c/3297: fixincludes (?) removes pthread types from types.h
Date: Wed, 20 Jun 2001 17:36:28 -0400

 Bruce Korb wrote:
 > 
 > It works for me  :-)
 > Of course, this is Solaris2.8.
 
 I think I've got a theory now that doesn't make gcc at fault at all.
 
 We have had a number of different machines, some with older and some with
 newer versions of Solaris (2.5 - 2.7).  They all share a common /usr/local
 tree, which previously hasn't been a problem.  Previous versions of gcc
 didn't need to tweak sys/types.h, so each machine saw its own local
 sys/types.h.  As long as we did our builds on the older 2.5 machine,
 everything worked fine.
 
 The problem is that between 2.5 and 2.7, the types defined in pthread.h
 (and a few other places) moved into sys/types.h.  The result is that
 although fixincl is _correctly_ patching the 2.5 sys/types.h, this causes
 the 2.7 machines to suddenly see a (slight) modification of the 2.5 header,
 which is totally incompatible.
 
 As I see no reason whatsoever that what we're doing here (sharing
 /usr/local between machines with different versions of Solaris) should be
 supported by gcc, my conclusion (pending a test build to make sure I'm
 right) is that there is no gcc bug mangling headers; the problem is between
 keyboard and chair on our end.
 
 HOWEVER -- I think there is still a little bit of gcc misbehaviour here. 
 If I build gcc on a 2.5 machine then,
 even if I run it on a 2.7 machine, it still looks for its fixed headers in:
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.5/3.0/
 
 This suggests to me that this directory name is being built into gcc rather
 than generated from the actual operating system version.  If there are no
 fixed headers for the current version of solaris, it is not in general
 correct to use fixed headers from a previous version -- it would be
 preferable to give a useful error message or to fall back on the unfixed
 headers.
 
 To summarize:  The bug I've reported doesn't seem to be real.  But I am
 seeing bad behaviour because of a second (and really fairly minor) bug that
 gcc is using a gcc-lib subdir based on what it was built on rather than
 what the current system is really running.  This will cause people in a
 bogus state (eg using a 2.5-built compiler on 2.7) to see inexplicable
 failures rather than some useful indication that their current state is
 bogus (easily detectable from the absence of a lib/gcc-lib/foo subdir for
 foo=their OS version)
 
 In any case, the workaround on my end is pretty easy, so I'm out of the
 woods.  Thanks anyway!
  --Grant
 
 -- 
 Grant Gould   ggould@intouchsys.com   (grant.gould@comverse.com) 
 |    InTouch Systems     |     CNS Speech Portal Division    |
 | Comverse Speech Portal | Comverse Voice Solutions Division |
      **** Branding subject to change without notice! ****

Re: c/3297: fixincludes (?) removes pthread types from types.h

[aoliva]

Synopsis: fixincludes (?) removes pthread types from types.h

State-Changed-From-To: open->closed
State-Changed-By: aoliva
State-Changed-When: Wed Jun 20 17:14:02 2001
State-Changed-Why:
    If uname -a says SunOS 5.7, as your bug report does, that's the problem: GCC built on Solaris 2.5 gets fixed headers for Solaris 2.5, that won't work correctly on Solaris 7.  You'll have to build GCC on Solaris 7, and use that build on Solaris 7.   I.e., don't share /usr/local, or use different --exec-prefixes for each version of Solaris.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3297&database=gcc

c/3297: fixincludes (?) removes pthread types from types.h

[Grant Gould]

>Number:         3297
>Category:       c
>Synopsis:       fixincludes (?) removes pthread types from types.h
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 20 08:46:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Grant Gould
>Release:        3.0
>Organization:
Comverse Network Systems (Voice Solutions)
>Environment:
System: SunOS curley.intouchsys.com 5.7 Generic_106541-15 sun4m sparc SUNW,SPARCstation-5
Architecture: sun4

	
host: sparc-sun-solaris2.5
build: sparc-sun-solaris2.5
target: sparc-sun-solaris2.5
configured with: ../gcc-3.0/configure 
>Description:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.5/3.0/include/sys/types.h
does not define pthreads-related types.  Standard solaris headers in
/usr/include (such as /usr/include/time.h) rely on it doing so.  This
results in parse errors when these headers use pthread_attr_t and it
has not been provided by the #include<sys/types.h>

>How-To-Repeat:
Here's a copy-and-paste of my demonstration.  Note that hworld2.c is
legal, but will only compile if I explicitly force the use of the
headers in /usr/include rather than letting gcc use its fixed headers.

 $ curley $ cat hworld.c
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello, World!\n");
}
 $ curley $ cat hworld2.c
#include <time.h>
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello, World!\n");
}
 $ curley $ gcc hworld.c -o hworld
 $ curley $ ./hworld
Hello, World!
 $ curley $ gcc hworld2.c -o hworld2
In file included from hworld2.c:1:
/usr/include/time.h:131: parse error before "pthread_attr_t"
/usr/include/time.h:133: parse error before '}' token
 $ curley $ gcc hworld2.c -I/usr/include/ -o hworld2
 $ curley $ ./hworld2
Hello, World!

>Fix:
Well, you could leave the pthreads definitions in the fixed types.h --
I don't see why it is excised.

As it is, gcc leaves a situation where no simple #include line will
get you the pthread types.  That's no good.
>Release-Note:
>Audit-Trail:
>Unformatted: