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

[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/

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

[G. Sumner Hayes]

Andreas Jaeger (aj@arthur.rhein-neckar.de) wrote:
> --- /usr/glibc/glibc-2.0.5/glibc-2.0.5c-src/linuxthreads/sysdeps/pthread/libc-lock.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 */

Applying this patch does not fix things here on Red Hat 5.0.  I still
need to link all C++ programs against the pthreads library.

Should egcs and/or glibc be rebuilt after applying this?

-Sumner

-- 
rage, rage against the dying of the light

Re: Possible Showstopper

[Wolfram Gloger]

> Andreas Jaeger (aj@arthur.rhein-neckar.de) wrote:
> > +#  pragma weak _pthread_cleanup_push_defer
> > +#  pragma weak _pthread_cleanup_pop_restore
> 
> Applying this patch does not fix things here on Red Hat 5.0.  I still
> need to link all C++ programs against the pthreads library.

Yes, this is what I found as well.  A solution is to insert into
libc-lock.h

asm(".weakext _pthread_cleanup_push_defer");
asm(".weakext _pthread_cleanup_pop_restore");

instead of the `#pragma weak's.  This is rather ugly, but works for
me.

Regards,
Wolfram.
-- 
`Surf the sea, not double-u three...'
wmglo@dent.med.uni-muenchen.de

Re: Possible Showstopper

[Paul Henning]

This problem with -lpthreads and C++ does not seem limited to just
RedHat 5.0.  I have a heavily modified RedHat 4.2 system.  I built and
installed glibc-2.0.5c on it two days ago, and am having the same
problem when trying to test egcs-971201 on an i686-pc-linux-gnu host

So, my question is, how did RedHat and I build/install glibc-2.0.5c
differently than anyone else that isn't seeing this problem?

My suggestion is that we don't make the fix for the problem dependent
on detecting that we are on a RedHat 5.0 system.

Thanks,
Paul Henning

Re: Possible Showstopper

[Andreas Jaeger]

>>>>> G Sumner Hayes writes:

G> Applying this patch does not fix things here on Red Hat 5.0.  I still
G> need to link all C++ programs against the pthreads library.

G> Should egcs and/or glibc be rebuilt after applying this?
If you did apply the patch to the installed file you only need to
rebuild egcs AFAIK.

Andreas
-- 
 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/

Re: Possible Showstopper

[G. Sumner Hayes]

On Fri, Dec 05, 1997 at 03:23:12PM +0100, Andreas Jaeger wrote:
> >>>>> G Sumner Hayes writes:
> 
> G> Applying this patch does not fix things here on Red Hat 5.0.  I still
> G> need to link all C++ programs against the pthreads library.
> 
> G> Should egcs and/or glibc be rebuilt after applying this?
> If you did apply the patch to the installed file you only need to
> rebuild egcs AFAIK.

Okay, it worked.  Thanks.

-Sumner

-- 
rage, rage against the dying of the light