This is the mail archive of the libc-alpha@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: egcs fails to build libio


On Tue, 22 Dec 1998, Franz Sirl wrote:
...
> At 12:38 22.12.98 , Horst von Brand wrote:
> >Richard Ketchersid <ketchers@math.berkeley.edu> said:
> >> Here is what happens while trying to compile libio. 
> >> This has happened for the last few snapshots, at least since egcs-2.92.28.
> >> ========================================================================
> >> 
> >> test x"yes" != xyes || \
> >>   /usr/src/BUILD/egcs/gcc/xgcc -B/usr/src/BUILD/egcs/gcc/ 
> >>   -B/usr/i486-pc-linux-gnu/bin/ -c -D_GNU_SOURCE -g1 -pipe -O2 
> >>   -fvtable-thunks -fvtable-thunks -D_GNU_SOURCE -fno-implicit-templates 
> >>   -I. -I/usr/src1/CVS/EGCS/egcs/libio -nostdinc++ -D_IO_MTSAFE_IO 
> >>   -fpic /usr/src1/CVS/EGCS/egcs/libio/builtinbuf.cc -o pic/builtinbuf.o
> >> In file included from /usr/include/bits/stdio-lock.h:20,
> >>                  from /usr/src1/CVS/EGCS/egcs/libio/libio.h:166,
> >>                  from /usr/src1/CVS/EGCS/egcs/libio/streambuf.h:36,
> >>                  from /usr/src1/CVS/EGCS/egcs/libio/builtinbuf.h:32,
> >>                  from /usr/src1/CVS/EGCS/egcs/libio/builtinbuf.cc:29:
> >> /usr/include/pthread.h:451: Internal compiler error.
...
> >> cpp: output pipe has been closed
> >> make: *** [builtinbuf.o] Error 1
> >
> >Exactly what I see in i586-linux-gnu, glibc-2.0.108, binutils-2.9.1.0.19a,
> >linux-2.1.131ac13. The failure happens with, eg:
> >
> >extern void *f(unsigned int) throw();
> 
> Hmm, I get a similar failure (reported ~1 week ago) on glibc-2.0.106
> powerpc-unknown-linux-gnu. The core dump showed that cpp crashed in
> fileno_unlocked, because fileno_unlocked was handed a NULL (? no longer
> 100% sure about that) pointer. I thought cpp got miscompiled on PPC cause
> the contruct looked so simple: fileno(stdout). But now I'm no longer sure
> about that.
....

I currently using kernel-2.1.131ac13, glibc-2.0.108, egcs-1.1.1(patched 
with HJL's latest libgcc.map patch), binutils-2.9.1.0.19a, 
autoconf-2.12.2(cvs version), libg++-2.8.1.2a-19981218 on Pentium MMX
166 box with 64 MB EDO RAM.(if necessary, ASUS P/I-P55T2P4 rev. 3.10,
BIOS 0207, Quantumn F/B 1.28G and 5.1G HDD) 
I saw partly the same result as above report plus subsequent 2 more
error after modifying 434, 435 line of pthread.h.(Here I merely cut &
pasted relevant passages. Please, note that I used '-O9' as usual in
compiling egcs.)

....
test x"yes" != xyes || \
  /usr/src/redhat/BUILD/obj-egcs-19981220/gcc/xgcc
-B/usr/src/redhat/BUILD/obj-e
gcs-19981220/gcc/ -B/home/jinbo21/egcs/i586-pc-linux-gnu/bin/ -c -O9
-mcpu=pentium -march=pentium -fomit-frame-pointer -pipe -fvtable-thunks
-D_GNU_SOURCE -fno-implicit-templates -I. -I../../../egcs-19981220/libio 
-nostdinc++ -D_IO_MTSAFE_IO -fpic
../../../egcs-19981220/libio/parsestream.cc -o pic/parsestream.o
In file included from ../../../egcs-19981220/libio/parsestream.cc:32:
/usr/include/stdlib.h:470: Internal compiler error.
....

/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/xgcc 
-B/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/
-B/home/jinbo21/egcs/i586-pc-linux-gnu/bin/ -c -O9 -mcpu=pentium 
-march=pentium -fomit-frame-pointer -pipe -fvtable-thunks -D_GNU_SOURCE
-fno-implicit-templates -I. -I../../../egcs-19981220/libio -nostdinc++
-D_IO_MTSAFE_IO -fpic ../../../egcs-19981220/libio/builtinbuf.cc -o
pic/builtinbuf.o
                 from ../../../egcs-19981220/libio/libio.h:166,
                 from ../../../egcs-19981220/libio/streambuf.h:36,
                 from ../../../egcs-19981220/libio/builtinbuf.h:32,
                 from ../../../egcs-19981220/libio/builtinbuf.cc:29:
/usr/include/pthread.h:434: Internal compiler error.
...

/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/xgcc 
-B/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/
-B/home/jinbo21/egcs/i586-pc-linux-gnu/bin/ -c -O9 -mcpu=pentium 
-march=pentium -fomit-frame-pointer -pipe -fvtable-thunks -D_GNU_SOURCE
-fno-implicit-templates -I. -I../../../egcs-19981220/libio -nostdinc++
-D_IO_MTSAFE_IO -fpic ../../../egcs-19981220/libio/parsestream.cc -o
pic/parsestream.o
In file included from /usr/include/stdlib.h:488,
                 from ../../../egcs-19981220/libio/parsestream.cc:32:
/usr/include/alloca.h:33: Internal compiler error.
....

 This problem is similar to that which appeared 2-3 month ago between 
glibc-2.0.95(6?) and egcs devel version, when glibc-2.0.95(6?)
changed its code of libio to fully support execption handling. But, 
the differnece is that this probelm comes first from egcs part.

I could compile egcs-2.92.32(19981220 ss) by modifying relevant
part of /usr/include/{pthread,stdlib,alloca}.h.
It was simple. Just to replace '__P' to '__PMT' at lines above
mentioned will do. Of course, it is not for practical use, it was done 
only for compiler's sake as a experiment.  

BTW, I want to know more deeply about this problem and true 
causes and solution.
So, I read ChangeLogs of egcs-19981220, and compare important files such 
as stddef.h or so, but I didn't find out something remarkable except 
following passage and 'typeinfo' 
...
Wed Dec 16 17:30:35 1998  Nick Clifton  <nickc@cygnus.com>

        * toplev.c (main): Disable optimize_size if a specific
        optimization level is requested.  Always set optimization
        level to 2 if -Os is specified.
...
--- /usr/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.60/include/typeinfo
Wed Dec 16 04:24:32 1998
+++
/home/jinbo21/egcs/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.92.32/include/typein
fo      Tue Dec 22 05:41:18 1998
@@ -1,5 +1,5 @@
 // RTTI support for -*- C++ -*-
-// Copyright (C) 1994, 1995, 1996 Free Software Foundation
+// Copyright (C) 1994, 95-97, 1998 Free Software Foundation
 
 #ifndef __TYPEINFO__
 #define __TYPEINFO__
@@ -10,9 +10,7 @@
 
 extern "C++" {
 
-#ifdef __HONOR_STD
 namespace std {
-#endif
 
 class type_info {
 private:
@@ -21,7 +19,7 @@
   type_info (const type_info&);
 
 protected:
-  type_info (const char *n): _name (n) { }
+  explicit type_info (const char *n): _name (n) { }
 
   const char *_name;
 
@@ -54,9 +52,7 @@
   virtual ~bad_typeid () { }
 };
 
-#ifdef __HONOR_STD
 } // namespace std
-#endif
 
 } // extern "C++"
 #endif
....  

 These change is not documented well. Moreover, changes of 'typeinfo'
seems not to documented at all.(I recall '__HONOR_STD' was not the
default before egcs-2.92.32 due to instability of SGI STL code, but it
seems to be unconditional at the side of egcs, and accordingly
compells various C++ applications to use namespaces compliant
libstdc++-2.9.x now) 

 And, features.h of glibc-2.0.8 defines '__USE_EXTERN_INLINES__' as
follows:
...
/* Decide whether we can define 'extern inline' functions in headers.
*/
#if defined __GNUC__ && (__GNUC__ > 2 || __GNUC__ == 2 && __GNUC_MINOR__
>= 7)\
    && defined __OPTIMIZE__ && !defined __OPTIMIZE_SIZE__
# define __USE_EXTERN_INLINES   1
#endif
...

Here, I tended to be suspicious about 'optimize_size' change
of egcs-2.92.32, and tested 2 cases as follows:

First, I tried to compile builtinbuf.cc without optimization, but the
result was the same.(failure)

I did 'make -k check-targe-libio' after inserting similar macro
to above example into /usr/include/{pthread,stdlib,alloca}.h and
replacing '-O2'(or -O9) with '-Os' in egcs-19981220/gcc/libio/Makefile
as a experiment. 
For example,  
...
#if defined __OPTIMIZE__ && !defined __OPTIMIZE_SIZE__ 
extern __ptr_t malloc __PMT ((size_t __size));
#else
extern __ptr_t malloc __P ((size_t __size));
#endif 
...
It seems to work now. the results of 'make -k check' was as usual. 

But, if I removed the inserted macro defines(ie., restored orinal header
files) and used only '-Os', egcs-2.92.32 could not pass testsuites of
libio and libg++, g++ successfully.(results of gcc, g77, libobjc were
not affected by any case. This problem ocurrus in relation with libio,
libstdc++, libg++)
In short, the result of g++ tests as follows:
........................................................................

1. a case of success after relevant header files of glibc-2.0.108

                === libio Summary ===

# of expected passes            40

                === libstdc++ Summary ===

# of expected passes            30

                === libg++ Summary ===

# of expected passes            72

                === gcc Summary ===

# of expected passes            4782
# of unexpected failures        4
# of unexpected successes       1
# of expected failures          86
# of untested testcases         7

                === g++ Summary ===

# of expected passes            4782
# of unexpected failures        4
# of unexpected successes       1
# of expected failures          86
# of untested testcases         7

                === g77 Summary ===

# of expected passes            465

                === objc Summary ===

# of unexpected failures        19
# of untested testcases         19

/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/testsuite/../xgcc version 
egcs-2.92.32 19981220 (gcc2 ss-980609 experimental)


2. a case of failed test with orignal header files of glibc-2.0.108

                === libio Summary ===

# of expected passes            7
# of unexpected failures        11
# of expected failures          22

                === libstdc++ Summary ===

# of expected passes            6
# of unexpected failures        8
# of expected failures          16

                === libg++ Summary ===

# of expected passes            15
# of unexpected failures        19
# of expected failures          38

                === gcc Summary ===

# of expected passes            7811
# of unexpected failures        28
# of expected failures          13
# of unsupported tests          12

                === g++ Summary ===

# of expected passes            4674
# of unexpected failures        64
# of unexpected successes       1
# of expected failures          85
# of untested testcases         7

                === g77 Summary ===

# of expected passes            465

                === objc Summary ===

# of unexpected failures        19
# of untested testcases         19

/usr/src/redhat/BUILD/obj-egcs-19981220/gcc/testsuite/../xgcc version
egcs-2.92.32 19981220 (gcc2 ss-980609 experimental)

.......................................................................

Anyhow, I temporarily concluded as follows:
1. Latest egcs is trying to more strictly compliant to ISO C9X, 
 and transient conflicts between glibc2 and egcs has exposed.
 But, I dont't know current changes of egcs-2.92.32 is accurate and
 adequate, though it seems to go to the accurate direction in rough
 sense.

2. Even before more thourough solution comes out, a workaround
 would be helpful. I hope a macro, ie., '__GNUC_TEENY__' as is 
 similar thing in XFree86's linux.cf, would be helpful in such
 transient situation. If such thing is present, above situation
 is easy to sove. Just to change above relevant codes to  

#if defined __GNUC__ && (__GNUC__ >= 2 && \
		__GNUC_MINOR__ >= 92 && __GNUC_TEENY__ >= 32))'
extern ... __PMT((...));
#else
extern ... __P ((...));
#endif

 would be temporarily helpful workaround.

3. I didn't test whether egcs-2.92.32 could compile successfully and
 pass given testsuites ok or not, if we configured it without 
'--enable-threads' and used only '-Os' 

4. It might be the time for glibc-2.0.109 to be born. :-)


PS: I didn't try to compile anything with newly compiled egcs-2.92.32.
  So, it woulnd't be the time for me to say it is good or not.

-- 
 "Where there is a will, there is a way."  jinbo21@soback.kornet21.net 
                                           kbeyl@kids.kotel.co.kr      
  For the future of you and me!            hitel: jinbo21



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]