Possible Showstopper

Possible Showstopper

[Mark Mitchell]

The new 971201 snapshot did not fix the problem I am having on my
RedHat 5.0 system (i686-pc-linux-gnu).  In particular, make check
fails horribly for many C++ tests, like this:

/mnt/u1/mitchell/projects/egcs/objdir/libraries//libstdc++/libstdc++.so: undefined reference to `_pthread_cleanup_pop_restore'
/mnt/u1/mitchell/projects/egcs/objdir/libraries//libstdc++/libstdc++.so: undefined reference to `_pthread_cleanup_push_defer'
collect2: ld returned 1 exit status

I understand that these functions are defined in libpthread, but if
this library is needed, then egcs should be linking it in by default.
At the very least, something needs to go in the release notes about
this.  More probably, we need to work out a fix.  I don't understand
enough about the way glibc works to know how to fix this, but I'm
happy to answer any questions about my system that might help folks.
My system is a completely stock RedHat 5.0, so we can be sure I won't
be the only one to run into this problem!

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: Possible Showstopper

[Jeffrey A Law]

  In message < 199712022253.OAA06067@supernova.earthlink.net >you write:
  > 
  > The new 971201 snapshot did not fix the problem I am having on my
  > RedHat 5.0 system (i686-pc-linux-gnu).  In particular, make check
  > fails horribly for many C++ tests, like this:
With RedHat only being out for 2 days I think the way to go is to make a minor
release in a week or so to fix this specific problem.

  > At the very least, something needs to go in the release notes about
  > this.
Agreed.

jeff

Re: Possible Showstopper

[Neal Becker]

You can fix this by editing /usr/include/libc-lock.h.  I don't have
the info in front of me, but it's to put declarations

#ifdef __ELF__
#pragma weak xxx

for the two offending symbols.  I use a homespun system including
glibc-2.0.5.

Re: Possible Showstopper

[Joe Buck]

>   In message < 199712022253.OAA06067@supernova.earthlink.net >you write:
>   > 
>   > The new 971201 snapshot did not fix the problem I am having on my
>   > RedHat 5.0 system (i686-pc-linux-gnu).  In particular, make check
>   > fails horribly for many C++ tests, like this:
> With RedHat only being out for 2 days I think the way to go is to make a minor
> release in a week or so to fix this specific problem.
> 
>   > At the very least, something needs to go in the release notes about
>   > this.
> Agreed.

Will it work around the problem if users add -lpthread to their link
line?

(Yes, it sucks that we got burned by 5.0, but we did want to support
popular Linux distributions).

Re: Possible Showstopper

[Jeffrey A Law]

  In message < 199712031733.JAA25765@atrus.synopsys.com >you write:
  > Will it work around the problem if users add -lpthread to their link
  > line?
Dunno.  RTH has a CD on order; hopefully it'll arrive soon, we can then
do whatever is necessary to support 5.0 and spin a release with 5.0
support within a week or two.


  > (Yes, it sucks that we got burned by 5.0, but we did want to support
  > popular Linux distributions).
Yup.  I think this is important enough to make a minor release as soon
as we've got 5.0 support.

jeff

Re: Possible Showstopper

[Mark Mitchell]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

    Jeffrey>   In message
    Jeffrey> < 199712031733.JAA25765@atrus.synopsys.com >you write:
    >> Will it work around the problem if users add -lpthread to their
    >> link line?
    Jeffrey> Dunno.  RTH has a CD on order; hopefully it'll arrive
    Jeffrey> soon, we can then do whatever is necessary to support 5.0
    Jeffrey> and spin a release with 5.0 support within a week or two.

Several people have suggested adding an #ifdef __ELF around some
pragmas in libc-lock.h.  Could we just supply a corect version of this
file, and install it if we detect RH 5.0?  That should be easy.

    >> (Yes, it sucks that we got burned by 5.0, but we did want to
    >> support popular Linux distributions).
    Jeffrey> Yup.  I think this is important enough to make a minor
    Jeffrey> release as soon as we've got 5.0 support.

    Jeffrey> jeff

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

genattr Error code 139

[Dax Kelson]

Solaris 2.6 x86

I'm trying to build egcs-1.0 w/ gcc version egcs-2.90.10p 970924 (which
succesfully compiled)

./configure --enable-haifa

It dies at this point:

stage1/xgcc -Bstage1/  -DIN_GCC   -O2 -g -O2   -DHAVE_CONFIG_H -DHAIFA  -o
genattr \
 genattr.o rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case
"alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo  ;; esac `   
./genattr ./config/i386/i386.md > tmp-attr.h
*** Error code 139
make: Fatal error: Command failed for target `stamp-attr'
Current working directory /export/home/dkelson/software/egcs-1.0/gcc
*** Error code 1
make: Fatal error: Command failed for target `bootstrap'
Current working directory /export/home/dkelson/software/egcs-1.0/gcc
*** Error code 1
make: Fatal error: Command failed for target `bootstrap'

It seems that genattr is dumping core.  I also tried without
--enable-haifa and using gcc 2.7.2 and had the same results.

I tried with gnu make 3.76.1 as well as the Sun supplied make.

Help?

Dax Kelson
Internet Connect, Inc.

Re: genattr Error code 139

[Jeffrey A Law]

  In message < Pine.GSO.3.96.971203172507.458C-100000@brookie >you write:
  > 
  > Solaris 2.6 x86
  > 
  > I'm trying to build egcs-1.0 w/ gcc version egcs-2.90.10p 970924 (which
  > succesfully compiled)
  > 
  > ./configure --enable-haifa
  > 
  > It dies at this point:
  > 
  > stage1/xgcc -Bstage1/  -DIN_GCC   -O2 -g -O2   -DHAVE_CONFIG_H -DHAIFA  -o
  > genattr \
  >  genattr.o rtl.o ` case "obstack.o" in ?*) echo obstack.o ;; esac ` ` case
  > "alloca.o" in ?*) echo alloca.o ;; esac ` ` case "" in ?*) echo  ;; esac ` 
  >   
  > ./genattr ./config/i386/i386.md > tmp-attr.h
  > *** Error code 139
Hmm, this sounds similar to a x86-solaris2.5 problem that some folks
have had.  I believe the problem had something to do with inproper
padding of the .init/.fini sections by either the assembler or linker.

I don't think we ever got a resolution of this problem.  I do not the
following in i386/sol2.h:

/* The Solaris 2.0 x86 linker botches alignment of code sections.
   It tries to align to a 16 byte boundary by padding with 0x00000090
   ints, rather than 0x90 bytes (nop).  This generates trash in the
   ".init" section since the contribution from crtbegin.o is only 7
   bytes.  The linker pads it to 16 bytes with a single 0x90 byte, and
   two 0x00000090 ints, which generates a segmentation violation when
   executed.  This macro forces the assembler to do the padding, since
   it knows what it is doing. */

I wonder if we're missing a FORCE_INIT_SECTION_ALIGN or FORCE_FINI_SECTION_ALIGN
somewhere.

Can you send us I disassembly dump for the .init section and the .fini
section?

jeff

Re: Possible Showstopper

[Andreas Jaeger]

>>>>> Joe Buck writes:

>> In message < 199712022253.OAA06067@supernova.earthlink.net >you write:
>> > 
>> > The new 971201 snapshot did not fix the problem I am having on my
>> > RedHat 5.0 system (i686-pc-linux-gnu).  In particular, make check
>> > fails horribly for many C++ tests, like this:
>> With RedHat only being out for 2 days I think the way to go is to make a minor
>> release in a week or so to fix this specific problem.
>> 
>> > At the very least, something needs to go in the release notes about
>> > this.
>> Agreed.

 > Will it work around the problem if users add -lpthread to their link
 > line?
That might work but is unneccassary.
 > (Yes, it sucks that we got burned by 5.0, but we did want to support
 > popular Linux distributions).

A better solution is to change
linuxthreads/sysdeps/pthread/libc-lock.h (it's installed as
/usr/include/libc-lock.h) with the following patch (it's a bug in the
current glibc 2.0.5c):

Andreas

--- /usr/glibc/glibc-2.0.5/glibc-2.0.5c-src/linuxthreads/sysdeps/pthread/libc-lo
ck.h    Mon Aug 18 16:01:50 1997
+++ linuxthreads/sysdeps/pthread/libc-lock.h    Wed Nov 19 00:47:11 1997

@@ -166,6 +166,11 @@
 /* We need portable names for some functions.  E.g., when they are
    used as argument to __libc_cleanup_region_start.  */
 # define __libc_mutex_unlock __pthread_mutex_unlock
+#else
+# ifdef __ELF__
+#  pragma weak _pthread_cleanup_push_defer
+#  pragma weak _pthread_cleanup_pop_restore
+# endif
 #endif
 
 #endif /* bits/libc-lock.h */


-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@alma.student.uni-kl.de
    http://www.student.uni-kl.de/~ajaeger/