[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IA64 HP-UX libtool / gcc question about shared libraries
From: |
Gerald Pfeifer |
Subject: |
Re: IA64 HP-UX libtool / gcc question about shared libraries |
Date: |
Mon, 15 Dec 2008 11:37:43 +0100 (CET) |
User-agent: |
Alpine 1.99 (LSU 1142 2008-08-13) |
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/
- Re: IA64 HP-UX libtool / gcc question about shared libraries,
Gerald Pfeifer <=