Problems bootstrapping on i686-linux

Problems bootstrapping on i686-linux

[Adam Schrotenboer]

during bootstrap, gcc 3.0 release  barfs on gthr.[ch] (can't remember for
sure, from memory) in libstdc++, bad preprocessor directives #_GLIBC_*

Any ideas people???

PATCH for gthr.h (was:: Problems bootstrapping on i686-linux)

[Carlo Wood]

On Mon, Jun 18, 2001 at 04:57:50PM -0400, Adam Schrotenboer wrote:
> during bootstrap, gcc 3.0 release  barfs on gthr.[ch] (can't remember for
> sure, from memory) in libstdc++, bad preprocessor directives #_GLIBC_*
> 
> Any ideas people???

I think the following patch is needed.
Can someone make sure this makes it into 3.01? :)


Index: gcc/gthr.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gthr.h,v
retrieving revision 1.7
diff -u -d -p -r1.7 gthr.h
--- gthr.h	2000/01/27 18:49:12	1.7
+++ gthr.h	2001/06/19 03:27:00
@@ -82,11 +82,11 @@ Boston, MA 02111-1307, USA.  */
 
 /* Check first for thread specific defines. */
 #if _PTHREADS
-#include "gthr-posix.h"
+#include "bits/gthr-posix.h"
 #elif _DCE_THREADS
 #include "gthr-dce.h"
 #elif _SOLARIS_THREADS
-#include "gthr-solaris.h"
+#include "bits/gthr-solaris.h"
 
 /* Include GTHREAD_FILE if one is defined. */
 #elif defined(HAVE_GTHR_DEFAULT)
@@ -95,11 +95,11 @@ Boston, MA 02111-1307, USA.  */
 #define GTHREAD_USE_WEAK 1
 #endif
 #endif
-#include "gthr-default.h"
+#include "bits/gthr-default.h"
 
 /* Fallback to single thread definitions. */
 #else
-#include "gthr-single.h"
+#include "bits/gthr-single.h"
 #endif
 
 #endif /* not __gthr_h */



-- 
Carlo Wood <carlo@alinoe.com>

Re: PATCH for gthr.h (was:: Problems bootstrapping on i686-linux)

[Alexandre Oliva]

On Jun 19, 2001, Carlo Wood <carlo@alinoe.com> wrote:

> I think the following patch is needed.

Wouldn't it break the build, since bits doesn't exist at that time?

Besides, I don't see why this is needed.  Since both gthr.h and
gthr-*.h are installed in the same bits directory, #include "gthr-*.h"
should get the right file from gthr.h.  If it doesn't, it's probably a
preprocessor bug.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

libstdc++/3243: Re: PATCH for gthr.h (was:: Problems bootstrapping on i686-linux)

[Carlo Wood]

On Tue, Jun 19, 2001 at 07:06:12AM -0300, Alexandre Oliva wrote:
> On Jun 19, 2001, Carlo Wood <carlo@alinoe.com> wrote:
> 
> > I think the following patch is needed.
> 
> Wouldn't it break the build, since bits doesn't exist at that time?
> 
> Besides, I don't see why this is needed.  Since both gthr.h and
> gthr-*.h are installed in the same bits directory, #include "gthr-*.h"
> should get the right file from gthr.h.  If it doesn't, it's probably a
> preprocessor bug.

You're right.  However, I feel the real problem might be the use of
double quotes here(?).

Anyway, here is a test case, the problem is indeed related to use of -I-.

-------Start of test.cc--------
#include <iostream>
-------End of test.cc----------

>g++-3.0 -I- -c -v test.cc
Reading specs from /usr/local/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0/specs
Configured with: ../gcc-3.0/configure --prefix=/usr/local/gcc-3.0 --infodir=/usr/local --mandir=/usr/local --enable-shared --with-gnu-as --with-gnu-ld --enable-threads=posix --enable-languages=c++ --disable-nls
Thread model: posix
gcc version 3.0
 /usr/local/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0/cc1plus -v -I- -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_GNU_SOURCE -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ test.cc -D__GNUG__=3 -D__GXX_DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -quiet -dumpbase test.cc -version -o /tmp/ccAiAD8o.s
GNU CPP version 3.0 (cpplib) (i386 Linux/ELF)
GNU C++ version 3.0 (i686-pc-linux-gnu)
	compiled by GNU C version 3.0.
ignoring nonexistent directory "/usr/local/gcc-3.0/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/gcc-3.0/include/g++-v3
 /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu
 /usr/local/gcc-3.0/include/g++-v3/backward
 /usr/local/include
 /usr/local/gcc-3.0/lib/gcc-lib/i686-pc-linux-gnu/3.0/include
 /usr/include
End of search list.
In file included from /usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/c++io.h:37,
                 from /usr/local/gcc-3.0/include/g++-v3/bits/fpos.h:39,
                 from /usr/local/gcc-3.0/include/g++-v3/bits/std_iosfwd.h:41,
                 from /usr/local/gcc-3.0/include/g++-v3/bits/std_ios.h:39,
                 from /usr/local/gcc-3.0/include/g++-v3/bits/std_ostream.h:39,
                 from /usr/local/gcc-3.0/include/g++-v3/bits/std_iostream.h:40,
                 from /usr/local/gcc-3.0/include/g++-v3/iostream:31,
                 from test.cc:1:
/usr/local/gcc-3.0/include/g++-v3/i686-pc-linux-gnu/bits/gthr.h:98:26: gthr-default.h: No such file or directory
[...]


-- 
Carlo Wood <carlo@alinoe.com>

Re: Problems bootstrapping on i686-linux

[Loren James Rittle]

In article < 20010618165750.A7505@tabris.domedata.com > you write:
> during bootstrap, gcc 3.0 release  barfs on gthr.[ch] (can't remember for
> sure, from memory) in libstdc++, bad preprocessor directives #_GLIBC_*

Normally I would tell people to file a GNATS report but since you are
seeing this failure on a platform that is known to work with the new
libstdc++ configuration, please send the following directly to me:

- The exact command line you used to configure.
- All output from ``make bootstrap''.

[In the future, send reports to gcc-bugs and/or file in GNATS.]

Regards,
Loren

Re: PATCH for gthr.h (was:: Problems bootstrapping on i686-linux)

[Loren James Rittle]

> I think the following patch is needed.
> Can someone make sure this makes it into 3.01? :)

Um, Adam has a completely different problem than you.

Your patch is not right.  If anything other than general bug fixes
needs to be done to the gthr*.h files before they are installed for
use by libstdc++-v3, it must be done at the staging time.

Regards,
Loren

Re: PATCH for gthr.h (was:: Problems bootstrapping on i686-linux)

[Loren James Rittle]

> Wouldn't it break the build, since bits doesn't exist at that time?

Yes, it would break builds since (at the very least) libobjc still
uses the gthr.h files right out of gcc/.

> Besides, I don't see why this is needed.  Since both gthr.h and
> gthr-*.h are installed in the same bits directory, #include "gthr-*.h"
> should get the right file from gthr.h.  If it doesn't, it's probably a
> preprocessor bug.

Had I known of this issue (i.e. bug or no bug in preprocessor), I
would have inserted the bits/ path to the include line while staging
gthr*.h files for libstdc++-v3.

However, since we are now where we are, I suppose Neil/Zack should
comment on this case.  In user code:

#include <X>

X is found in a system header which has this line:

#include <bits/Y.h>

bits/Y.h is found in a system header which has this line:

#include "Z.h"

Z.h is found in the same directory as Y.h was found (which is not a
visible top-level system directory itself).

This worked unless -I- was given on the compiler command line.

[If you agree this is a preprocessor issue, please take ownership of
 c++/3243 and reclassify it as appropriate. ;-) ]

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672

Re: Problems bootstrapping on i686-linux

[Loren James Rittle]

In article < 20010618165750.A7505@tabris.domedata.com > you write:
> during bootstrap, gcc 3.0 release  barfs on gthr.[ch] (can't remember for
> sure, from memory) in libstdc++, bad preprocessor directives #_GLIBC_*
>
> Any ideas people???

OK, later report (also sent to the wrong list, please use the gcc-bugs
mailing list or the GNATS available from http://gcc.gnu.org/ people ;-)
have confirmed this problem to be related to a bad sed on Mandrake 8.0
and/or a non-portable use of sed.

It will be resolved ASAP.

Regards,
Loren

Re: PATCH for gthr.h (was:: Problems bootstrapping on i686-linux)

[Neil Booth]

Loren James Rittle wrote:-

> However, since we are now where we are, I suppose Neil/Zack should
> comment on this case.  In user code:
> 
> #include <X>
> 
> X is found in a system header which has this line:
> 
> #include <bits/Y.h>
> 
> bits/Y.h is found in a system header which has this line:
> 
> #include "Z.h"
> 
> Z.h is found in the same directory as Y.h was found (which is not a
> visible top-level system directory itself).
> 
> This worked unless -I- was given on the compiler command line.

The behaviour is well documented, particularly after Zack's CPP manual
rewrite.  -I- turns off searching the directory of the current file,
so CPP is behaving as expected.

If you wish to change this behaviour, then we need to think about it
properly.  In particular, why, historically, was -I- given the
behaviour is has now?  Would other stuff break?  Is the behaviour you
describe what we want?  Why is a system header using #include ""
anyway?

Neil.

Re: PATCH for gthr.h (was:: Problems bootstrapping on i686-linux)

[Loren James Rittle]

In article < 20010620071400.B23386@daikokuya.demon.co.uk >,
Neil Booth <neil@daikokuya.demon.co.uk> writes:

>> However, since we are now where we are, I suppose Neil/Zack should
>> comment on this case.  In user code:
[...]
>> This worked unless -I- was given on the compiler command line.
[...]
> The behaviour is well documented, particularly after Zack's CPP manual
> rewrite.  -I- turns off searching the directory of the current file,
> so CPP is behaving as expected.

Thank you for the analysis.  I should read the CPP manual now that
Zack created a new manual.  (After reading selected passages from said
manual, I completely agree with your analysis.)

> If you wish to change this behaviour, then we need to think about it
> properly.  In particular, why, historically, was -I- given the
> behaviour is has now?  Would other stuff break?  Is the behaviour you
> describe what we want?  Why is a system header using #include ""
> anyway?

I do not want anything changed in CPP.  I only wanted to know whether
I introduced a subtle bug or whether Alex's analysis was correct.  In
light of your analysis (and I also read Zack's point about current
behavior existing since at least 2.7.2), I have assigned the PR to
myself and will fix it solely within libstdc++-v3.  Not that it
matters but it is an easy fix for us.

Regards,
Loren

Re: PATCH for gthr.h (was:: Problems bootstrapping on i686-linux)

[Neil Booth]

Loren James Rittle wrote:-

> I do not want anything changed in CPP.  I only wanted to know whether
> I introduced a subtle bug or whether Alex's analysis was correct.  In
> light of your analysis (and I also read Zack's point about current
> behavior existing since at least 2.7.2), I have assigned the PR to
> myself and will fix it solely within libstdc++-v3.  Not that it
> matters but it is an easy fix for us.

Ah, OK.  I'd had the impression it was not easy to fix in libstdc++.
That's great, then.

Neil.