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

[Grant Gould <ggould@intouchsys.com>]

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! ****