GCC 2.95: pthreads always required for C++ exception handling for *-*-hpux

[Becker_Stefan at nmp dot nokia dot com]

GCC version: 2.95
Target     : hppa1.1-hp-hpux10.20 (native)
Configure  : --enable-shared --enable-version-specific-runtime-libs
--with-gnu-as

When you compile a C++ program which includes exception handling or
inherits exception handling through some function in libstdc++ you always
need to link against -ldce, regardless if you compile your program with
or without -threads.

In the case of dynamic linking the link doesn't even fail, but the binary
aborts with a runtime dynamic linking error:

dir> cat dummy.cpp
#include <stream.h>

int main(int argc, char **argv)
{

 try {
  cout << "Hello, world!\n";
 } catch(...) {
 }

 return(0);
} 
dir> g++ -o dummy dummy.cpp
dir> ./dummy
/usr/lib/dld.sl: Unresolved symbol: pthread_once (code)  from
/appl/build/tmp/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.95/libstdc++.sl
ABORT instruction (core dumped)    
dir> g++ -o dummy dummy.cpp -ldce
dir> ./dummy
Hello, world!
dir>

The problem lies within libgcc.a: The exception handling code from
libgcc2.c always gets compiled WITH threads enabled even for the
non-threads version, see the following nm output:

gcc> pwd
/appl/build/hppa1.1-hp-hpux10.20/gcc-2.95/hppa1.1-hp-hpux10.20/gcc
gcc> nm libgcc.a | fgrep pthread
pthread_getspecific |          |undef |code   |
pthread_keycreate   |          |undef |code   |
pthread_once        |          |undef |code   |
pthread_setspecific |          |undef |code   |
gcc> nm threads/libgcc.a | fgrep pthread
pthread_getspecific |          |undef |code   |
pthread_keycreate   |          |undef |code   |
pthread_once        |          |undef |code   |
pthread_setspecific |          |undef |code   |
bosw27:gcc> 

When the shared version of libstdc++ is created it is linked against
-lgcc and thus always includes the exception handling code with the
references to pthreads.

The exception handling code from libgcc2.c should not be compiled with
threads support when creating the non-thread version of libgcc.a. (Or is
there some hidden reason why it is needed also in the non-thread case?)

Regards,

	Stefan

---
Stefan Becker
E-Mail: Stefan.Becker@nmp.nokia.com