Re: [3.1] More regressions on S/390 - revert lib64 patch

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Apr 26, 2002 at 09:01:31PM +0200, Ulrich Weigand wrote:
> Hello Mark,
> 
> we've unfortunately discovered another serious regression on s390, this
> time caused by the recent change to support /usr/lib64 systems.
> 
> Due to this change, the start files (crti.o etc.) are now always used
> from the absolute path given (/usr/lib/crti.o or /usr/lib64/crti.o).
> This differs from the previous behaviour where the compiler driver
> searched various directories (hard-coded /usr/lib as well as prefixes
> specified by the backend and -B command line switches) for a file
> named crti.o.
> 
> Unfortunately, current glibc versions rely on this search algorithm:
> when building libpthread.so, it is necessary to use a special variant
> of crti.o, which calls additional initialization routines, instead of
> the system crti.o.  The glibc Makefile achieves this by passing an
> -B argument specifying the libpthread build directory to the gcc
> driver when linking libpthread.so.  This caused the crti.o file found
> there to be used.
> 
> After the recent patch, the gcc driver always uses the system crti.o
> file, which means that the special libpthread init routines are not
> called when libpthread.so is loaded.  This causes a variety of serious
> problems with any application using threads (often crashes on startup).
> 
> 
> It appears that a proper fix for this problem is not easy; therefore
> I'd like to simply revert this patch for the 3.1 release.  OK?

Have you read
libc/linuxthreads/sysdeps/unix/sysv/linux/sparc/sparc64/Makefile
?
I agree the proper fix is to teach gcc driver about all this
*/lib{,64,n32,o32,/sparcv9} etc. stuff, but that cannot happen for
3.1.

	Jakub