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 [EMAIL PROTECTED] _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
