old release question: glibc-2.2.5 + gcc-3.4.0 generate static apps that segfault at startup?

[Dan Kegel]

Wolfram Gloger wrote:
> Hi,
> 
> 
>>glibc-2.3.2 works for me, but I'm also using an older release, 2.2.5,
>>and was hoping someone here would remember something about this issue.
>>
>>I built a gcc-3.4.0-glibc-2.2.5 toolchain for i686,
> 
> 
> How did you sucessfully build gcc-3.4 (or -3.3, anything > 3.2) with
> glibc-2.2.5?  Did you perhaps build C only (no g++)?  glibc-2.2.5 has
> several occurences of __thread in its header files, which is a keyword
> in newer gccs.
> 
> Building _anything_ that involves thread support with such a gcc on
> glibc-2.2.5 always failed for me.

I applied
http://kegel.com/crosstool/current/patches/glibc-linuxthreads-2.2.5/threadparam.patch
to fix that.  (That's one of the 28 patches for glibc-2.2.5 I have
found are neccesary for building and testing glibc-2.2.5 on the
platforms I've been using it on.  Like many of them, it's just
taken straight from glibc cvs.  All of them are applied automatically
when you build a toolchain using http://kegel.com/crosstool.)

>>(gdb) bt
>>#0  0x00000000 in ?? ()
>>#1  0x08048850 in ptmalloc_init () at malloc.c:1756
> 
> 
> Maybe this also has to do with some subtle __thread-related problem?

Could be.  A related problem seems to be that compiling the same
trivial program with -static -pthread shows conflicts in three symbols:

i686-unknown-linux-gnu/lib/libpthread.a(lockfile.o)(.text+0x0): In function `__flockfile':
glibc-2.2.5/linuxthreads/lockfile.c:37: multiple definition of `__flockfile'
i686-unknown-linux-gnu/lib/libc.a(lockfile.o)(.text+0x0):../sysdeps/generic/lockfile.c:28: first defined here
i686-unknown-linux-gnu/bin/ld: Warning: size of symbol `__flockfile' changed from 5 in i686-unknown-linux-gnu/lib/libc.a(lockfile.o) to 24 in i686-unknown-linux-gnu/lib/libc.a(lockfile.o)
i686-unknown-linux-gnu/lib/libpthread.a(lockfile.o)(.text+0x18): In function `__funlockfile':
glibc-2.2.5/linuxthreads/lockfile.c:52: multiple definition of `__funlockfile'
i686-unknown-linux-gnu/lib/libc.a(lockfile.o)(.text+0x5):../sysdeps/generic/lockfile.c:39: first defined here
i686-unknown-linux-gnu/bin/ld: Warning: size of symbol `__funlockfile' changed from 5 in i686-unknown-linux-gnu/lib/libc.a(lockfile.o) to 24 in i686-unknown-linux-gnu/lib/libc.a(lockfile.o)
i686-unknown-linux-gnu/lib/libpthread.a(lockfile.o)(.text+0x30): In function `__ftrylockfile':
glibc-2.2.5/linuxthreads/lockfile.c:67: multiple definition of `__ftrylockfile'
i686-unknown-linux-gnu/lib/libc.a(lockfile.o)(.text+0xa):../sysdeps/generic/lockfile.c:50: first defined here
i686-unknown-linux-gnu/bin/ld: Warning: size of symbol `__ftrylockfile' changed from 10 in i686-unknown-linux-gnu/lib/libc.a(lockfile.o) to 24 in i686-unknown-linux-gnu/lib/libc.a(lockfile.o)
collect2: ld returned 1 exit status

And *that* error even happens with gcc-3.3.3.
(FWIW, I've tried a couple very recent binutils, but haven't
verified that this is not a binutils problem.)

I'm a bit mystified by it all, but don't have time to look into it at the moment.
Maybe later.
(You can try it yourself by grabbing the latest snapshot of crosstool if you like.)
- Dan

-- 
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change