From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Gould To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: c/3297: fixincludes (?) removes pthread types from types.h Date: Wed, 20 Jun 2001 14:46:00 -0000 Message-id: <20010620214602.11682.qmail@sourceware.cygnus.com> X-SW-Source: 2001-06/msg00859.html List-Id: The following reply was made to PR c/3297; it has been noted by GNATS. From: Grant Gould To: Bruce Korb , 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! ****