Steve et al, I don't think I have seen a response to this, and it might be the same issue that was causing quite many testsuite failures on i386-unknown-freebsd
If so, that would be GCC Bugzilla Bug 35114, "731 unexpected libgomp testsuite failures due setup of test environment", or http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35114 Looking at a recent i386-unknown-freebsd run at http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01196.html though, we have === libgomp Summary === # of expected passes 2262 # of unexpected failures 57 # of unsupported tests 2 so something seems to have been improved? Thoughts? Gerald On Tue, 4 Nov 2008, Steve Ellcey wrote: > 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 > s...@cup.hp.com > -- Gerald (Jerry) Pfeifer ger...@pfeifer.com http://www.pfeifer.com/gerald/ _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
