libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

libtool shouldn't automatically link against libc on hppa*-*-hpux*


From: John David Anglin
Subject: libtool shouldn't automatically link against libc on hppa*-*-hpux*
Date: Sat, 9 Feb 2008 22:50:40 -0500 (EST)

I have been looking at trying to resolve random failures of threaded
applications on hppa*-*-hpux11* built with GCC.  There are problems
with java and applications linked against libgomp.  There are a number
issues.

The first and main issue is libc contains pthread stubs.  As a result,
libpthread must be linked against before libc.  Some information on
this subject is here <http://docs.hp.com/en/1896/pthreads.html>.

The second issue is that multiple specifications of shared libraries
with -l doesn't work.  Only the first instance is used in a link.
libgcc_s should be linked against libpthread if a shared library
or executable uses POSIX threads.  In GCC 4.3, the compiler driver
now adds -lpthread in the correct location in both shared and
non-shared links.  It also adds -lc in the correction location.
Thus, it is not necessary for libtool to add -lc in shared links
and indeed it interferes with the linking against libgcc_s.

This fix isn't sufficient to getting threaded applications using
shared libraries to function correctly as the dynamic loader
effectively relinks applications.  It's been my experience the
binding mode matters (i.e., threaded applications behaive differently
when using deferred and immediate binding).  The 32 and 64-bit
runtimes use different search algorithms, depth and breadth first,
respectively.

I think it may be necessary to link threaded applications and shared
libraries using direct binding.  This would ensure that calls to pthread
functions bind to the functions in libpthread and not to the stubs
in libc.  However, to do this, we need to get the basic link order
correct in shared links.

I have attached a small change to stop linking against libc
in shared links.  This was against ltmain.sh in the GCC sources.
This should be against ltmain.in in the libtool sources.  The
same change might be relevant to ia64-hpux.

On hpux10, it's not necessary to link against libc in shared links.
There's only one libc version.  On hpux11.11, there are three libc
versions but in my experience applications are almost never linked
against the old versions.  HP never links shared its libraries
against libc.

Dave
-- 
J. David Anglin                                  address@hidden
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Index: ltmain.sh
===================================================================
--- ltmain.sh   (revision 131740)
+++ ltmain.sh   (working copy)
@@ -2827,6 +2827,9 @@
            # Rhapsody C library is in the System framework
            deplibs="$deplibs -framework System"
            ;;
+         hppa*-*-hpux*)
+           # Compiler inserts libc in the correct place for threads to work.
+           ;;
          *-*-netbsd*)
            # Don't link with libc until the a.out ld.so is fixed.
            ;;




reply via email to

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