[Top][All Lists]

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

Re: C++ shared library misses pthread dependency library

From: Bob Friesenhahn
Subject: Re: C++ shared library misses pthread dependency library
Date: Fri, 4 May 2007 09:56:23 -0500 (CDT)

On Fri, 4 May 2007, Peter Volkov wrote:

Hello list.

This question was already asked on this list [1] and gcc bug report
followed [2] but seems that there is no solution still. The problem is
that libtool uses -nostdlib gcc flag during linkage of shared library
which case gcc to drop -lpthread. Hence resulting library misses pthread
dependency and has undefined ptread_* symbols.

I think that this problem can likely be blamed on a GCC bug. GCC is queried for the libraries and linker path it uses, and it sometimes does not return the correct information. It should return correct information based on other options supplied but it apparently does not. We have already seen this issue when -m64 is supplied as an option.

While I was assured that shared library with missing dependency on
libpthread should work (just add -lpthread during final executable
linkage and application will use this library without problems) and even
has some advantages over normal library [3] I still think that libtool

Some platforms (e.g. Solaris) use "weak linkage" for the pthreads library so if it is not used in the link, the application runs in a non-thread-safe mode via stub functions. Some functions may then return errors.

should add explicitly -lpthread during linkage of C++ shared libraries.
-lpthread is required for g++ shared library because there is difference
in gcc and g++ which cause final executable linkage problem when

If the g++ shared library has a dependence on libpthread, then it should indicate this in the associated .la file. If there is no associated .la file or the .la file does not mention pthread, then there is either a platform bug or another GCC bug.

--as-needed ld flag is used and when program to be linked with shared
library does not have pthread_* functions itself [4]. In the current
situation we have to workaround this problem by adding libpthread by
ourselfs like in this bug report [5]. But as libtool should hide
platform specifics from us I think it's better to fix such issues in
first place. On the other hand libtool drops libpthread dependency but
does not restore it.

It seems that recently special support has been added to libtool to deal with pthread dependency. I don't remember the specifics.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

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