Although I have found the patch from bug 1031 helpful, there are still
circumstances in which symbol versioning evidently confuses ld.  In particular,
chains of shared libraries that link against both -lpthread and [GCC 4.0.1's]
libsupc++.a are problematic, with ld eventually deciding that a user library
defines some pthread_ symbols and subsequently reporting an error at the next stage:

gcc -pthreads -fpic -Dfunc=baz -Doldfunc=bar -c foo.cc -o baz.o
nm -p baz.o | grep pthread
gmake: [baz.o] Error 1 (ignored)
gcc -pthreads -fpic -Dfunc=bar -Doldfunc=foo -c foo.cc -o bar.o
nm -p bar.o | grep pthread
gmake: [bar.o] Error 1 (ignored)
gcc -pthreads -fpic -Dfunc=foo -c foo.cc -o foo.o
nm -p foo.o | grep pthread
0000000000 U pthread_cancel
gcc -pthreads -shared -o libfoo.so foo.o -lpthread -lsupc++
nm -p libfoo.so | grep pthread
0000000000 U pthread_cancel@@SUNW_0.9
0000000000 U pthread_getspecific@@SUNW_0.9
0000000000 U pthread_key_create@@SUNW_0.9
0000000000 U pthread_mutex_lock@@SUNW_0.9
0000000000 U pthread_mutex_unlock@@SUNW_0.9
0000000000 U pthread_once@@SUNW_0.9
0000000000 U pthread_setspecific@@SUNW_0.9
gcc -pthreads -shared -o libbar.so bar.o -L. -lfoo -lpthread -lsupc++
nm -p libbar.so | grep pthread
gmake: [libbar.so] Error 1 (ignored)
gcc -pthreads -shared -o libbaz.so baz.o -L. -lbar -lpthread -lsupc++
nm -p libbaz.so | grep pthread
0000000000 T pthread_cancel@@SUNW_0.9
0000000000 U pthread_getspecific@@SUNW_0.9
0000000000 U pthread_key_create@@SUNW_0.9
0000000000 U pthread_mutex_lock@@SUNW_0.9
0000000000 U pthread_mutex_unlock@@SUNW_0.9
0000000000 U pthread_once@@SUNW_0.9
0000000000 U pthread_setspecific@@SUNW_0.9
gcc -pthreads -shared -o libquux.so quux.o -L. -lbaz -lpthread -lsupc++
/netopt/gcc/4.0.1a/solaris10-sparc/bin/ld: ./libbaz.so: pthread_cancel: invalid
version 3 (max 0)
./libbaz.so: could not read symbols: Bad value
collect2: ld returned 1 exit status
gmake: *** [libquux.so] Error 1