Re: IA64 HP-UX libtool / gcc question about shared libraries

[Gerald Pfeifer]

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
> address@hidden
> 

-- 
Gerald (Jerry) Pfeifer   address@hidden   http://www.pfeifer.com/gerald/