IA64 HP-UX libtool / gcc question about shared libraries

[Steve Ellcey]

I have a libtool / gcc / libgomp / shared library question.  The problem
I have is that if I compile a C program with -fopenmp and run it on IA64
HP-UX I get:

$ ./x
/usr/lib/hpux32/dld.so: Unable to find library 'libgcc_s.so.0'.

The problem is that the GNU C compiler links the program against the
archive version of libgcc so that the main program does not need the
shared libgcc_s.so.  But the compiler also links in the shared version
of libgomp.so because the IA64 HP-UX linker picks shared libraries over
archive ones by default so it links in the shared libgomp.so.

The libgomp.so library has a dependency on libgcc_s.so but it doesn't
know where to find it because there is no library search path built in
to shared libraries.  This is because libtool used +nodefaultrpath to
stop the HP linker from putting a search path into the shared libraries
that it builds.

This problem does not occur with C++ or Fortran because those languages
link against the shared libgcc instead of the archive one and so
libgcc_s.so and a search path for it are in the main object.  If I
compile and link  with '-shared-libgcc -fopenmp', then the program will
run correctly.

So my question is:  should this be fixed in libtool or in GCC.

The fix in GCC, as far as I can see would be to use -shared-libgcc when
doing links where -fopenmp is used.  Or, more drastically, change GCC to
always use the shared libgcc on IA64 HP-UX.  The IA64 HP-UX system ships
without an archive version of libc so forcing it to  use a shared libgcc
may not be unreasonable.

To fix it in libtool I think we would have to stop using +nodefaultrpath
when building shared libraries so that there is a search path to use in
the shared libraries.  This seems simple but I am not sure about all the
ramifications of doing this and that makes me a bit nervous.

Any opinions or ideas on how (or where) this problem should be fixed?

Steve Ellcey
address@hidden