0.9.29, somethings wrong with linker or threading

[Kevin Day]

First off, good job with this version, for the most part it is
noticably working better than the previous versions.

I just ran into a problem with either posix threads (stable)
(LINUXTHREADS_OLD=y) or something weird going on with the dynamic
linker.

A simple file is used for testing purposes called test.c, its contents
are only "int main(){}"
Using gcc-4.1.2.

This works
# gcc test.c
# ./a.out

This does not
# gcc -lao test.c
# ./a.out
# Segfault

This does not
# gcc -lfuse test.c
# ./a.out
# Segfault

In all two cases above that segfault, directly adding -lpthread fixes
the segfault problem.
Looks like anything that depends on some library that links to
pthread, does not properly recursively link to the pthread (should
it?).
As noted by the test.c, no threading is directly done there, but if
threading is including in a linked library, runtime segfault occurs.

Here is the valgrind log for vim:

==18960==
==18960== Stack overflow in thread 1: can't grow stack to 0xBE2EDFFC
==18960==
==18960== Process terminating with default action of signal 11 (SIGSEGV)
==18960==  Access not within mapped region at address 0xBE2EDFFC
==18960==    at 0x4060BEB: _pthread_cleanup_push_defer (in
/lib/libuClibc-0.9.29.so)
==18960== Stack overflow in thread 1: can't grow stack to 0xBE2EDFF8
==18960==
==18960== Process terminating with default action of signal 11 (SIGSEGV)
==18960==  Access not within mapped region at address 0xBE2EDFF8
==18960==    at 0x400A194: _vgnU_freeres (in
/tools/lib/valgrind/x86-linux/vgpreload_core.so)

The ldd on vim:
	libncurses.so.6 => /lib/libncurses.so.6 (0xb7f75000)
	libiconv.so.2 => /lib/libiconv.so.2 (0xb7e97000)
	libperl.so => //lib/perl5/5.8.8/i686-linux-thread-multi/CORE/libperl.so
(0xb7d7d000)
	libm.so.0 => /lib/libm.so.0 (0xb7d71000)
	libutil.so.0 => /lib/libutil.so.0 (0xb7d6e000)
	libc.so.0 => /lib/libc.so.0 (0xb7cdc000)
	libintl.so.8 => /lib/libintl.so.8 (0xb7cd3000)
	libtinfo.so.6 => /lib/libtinfo.so.6 (0xb7ca9000)
	libdl.so.0 => /lib/libdl.so.0 (0xb7ca5000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb7c93000)
	libnsl.so.0 => /lib/libnsl.so.0 (0xb7c91000)
	libcrypt.so.0 => /lib/libcrypt.so.0 (0xb7c7c000)
	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f94000)

An ldd on libperl:
checking sub-depends for '/lib/libnsl.so.0'
	libc.so.0 => /lib/libc.so.0 (0xb7efd000)
	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f93000)
checking sub-depends for '/lib/libdl.so.0'
	libc.so.0 => /lib/libc.so.0 (0xb7e9e000)
	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f34000)
checking sub-depends for '/lib/libm.so.0'
	libc.so.0 => /lib/libc.so.0 (0xb7eba000)
	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f50000)
checking sub-depends for '/lib/libcrypt.so.0'
	libc.so.0 => /lib/libc.so.0 (0xb7ed4000)
	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f6a000)
checking sub-depends for '/lib/libutil.so.0'
	libc.so.0 => /lib/libc.so.0 (0xb7eaa000)
	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f40000)
checking sub-depends for '/lib/libpthread.so.0'
	libc.so.0 => /lib/libc.so.0 (0xb7ee0000)
	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f76000)
checking sub-depends for '/lib/libc.so.0'
	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7fcc000)
checking sub-depends for '/lib/libintl.so.8'
	libnsl.so.0 => /lib/libnsl.so.0 (0x00000000)
	libdl.so.0 => /lib/libdl.so.0 (0x00000000)
	libm.so.0 => /lib/libm.so.0 (0x00000000)
	libcrypt.so.0 => /lib/libcrypt.so.0 (0x00000000)
	libutil.so.0 => /lib/libutil.so.0 (0x00000000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00000000)
	libc.so.0 => /lib/libc.so.0 (0x00000000)
	libintl.so.8 => /lib/libintl.so.8 (0x00000000)
	not a dynamic executable

It looks like the address' were lost during the sub-depends step

-- 
Kevin Day