[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

Looking at a recent i386-unknown-freebsd run at
though, we have

                === libgomp Summary ===

    # of expected passes                2262
    # of unexpected failures    57
    # of unsupported tests              2
so something seems to have been improved?



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/ Unable to find library ''.
> 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  But the compiler also links in the shared version
> of because the IA64 HP-UX linker picks shared libraries over
> archive ones by default so it links in the shared
> The library has a dependency on 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
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]