Date: Wed, 1 Apr 2009 20:12:08 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Dmitry Marakasov <amdmi3@amdmi3.ru> Cc: freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: -pthread propagation Message-ID: <Pine.GSO.4.64.0904011954001.27704@sea.ntplx.net> In-Reply-To: <20090401231831.GS1964@hades.panopticon> References: <20090401231831.GS1964@hades.panopticon>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2 Apr 2009, Dmitry Marakasov wrote:
> Hi!
>
> I have a question about -pthread. Imagine the situation where one port
> installs shared library that uses threads, and other port links with
> this library. A question: should the second port explicitely add
> -pthread to linker flags?
Yes.
> For example, graphics/ilmbase is built with pthread support by default,
> but it's shared libraries are not linked with -pthread:
>
> % ldd /usr/local/lib/libIlmThread.so
> /usr/local/lib/libIlmThread.so:
> libIex.so.6 => /usr/local/lib/libIex.so.6 (0x2819c000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x28300000)
> libm.so.5 => /lib/libm.so.5 (0x281ad000)
> libc.so.7 => /lib/libc.so.7 (0x2808b000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281c6000)
>
> no libthr.so mention. Thus,
>
> % gcc helloworld.cc -lIlmThread -L/usr/local/lib
> /usr/local/lib/libIlmThread.so: undefined reference to `pthread_create'
>
> I assume this should be fixed in ilmbase instead of all dependent ports
> (for example, graphics/nvidia-texture-tools and graphics/devil, which
> supports the former), am I right? Btw, libIlmThread.la _does_ have
> -pthread in dependency_libs.
Yes, all ports that use libraries that create threads on
their behalf should use -pthread.
> However, I've encountered situations where linking with library
> linked with -pthread will succeed, but the resulting binary will not
> be broken. Example is games/battletanks:
This is probably because libc contains some simple thread
wrappers (mostly lock related stuff). They go unused unless
a thread is created (and libthr is explicitly brought in),
in which case those wrappers are overridden by libthr.
> When built as is (note that it has ${PTHREAD_LIBS} explicitely added to
> LDFLAGS), it runs without problems. However, if you remove
> ${PTHREAD_LIBS}, it'll still build successfully, but won't run:
>
> % bt
> [03:04:45.449][src/main.cpp:44] [notice] starting up... version: 5800 beta
> [03:04:45.449][src/main.cpp:46] [notice] mem avail: -1 mb
> terminate called after throwing an instance of '__gnu_cxx::__concurrence_lock_error'
> what(): __gnu_cxx::__concurrence_lock_error
> [1] 58620 abort (core dumped) bt
>
> I think that's linked with static variable initialization - it should
> be protected with a mutex in threaded environment, but it doesn't happen
> correctly when linking without -pthread, even if with -lthr.
It is possible for a library to be thread-aware and thread-safe.
In this case it can play pragma weak games with "pthread_create"
and only use locks if pthread_create resolves to a non-null
pointer.
> I'll be really grateful if someone explains what really happens when
> using -lpthread, and what happens in the above mentioned error case
> (cc'ing hackers@).
>
> So should -pthread be forced in ldflags
> 1) Only in ports that explicitely use threads
> 2) In all ports that link with -lthr implicitely, including through
> other ports?
It depends, libraries can be made thread-safe/aware as
above, and both threaded and non-threaded applications
can link with them just fine. Assuming those libraries
are smart about how they use the locking mechanisms,
and never use them unless they know that "pthread_create"
is present (or some other symbol not present in libc,
but present in libthr).
But for libraries that create threads, applications must
also link with -pthread (or -lpthread).
If you can understand it, you can see
src/contrib/gcc/gthr-posix.h for how libgcc is
thread-aware. A comment from that file:
/* On Solaris 2.6 up to 9, the libc exposes a POSIX threads
interface even if -pthreads is not specified. The
functions are dummies and most return an error value.
However pthread_once returns 0 without invoking the routine
it is passed so we cannot pretend that the interface is
active if -pthreads is not specified. On Solaris 2.5.1,
the interface is not exposed at all so we need to play the
usual game with weak symbols. On Solaris 10 and up, a
working interface is always exposed. On FreeBSD 6 and
later, libc also exposes a dummy POSIX threads interface,
similar to what Solaris 2.6 up to 9 does. FreeBSD >=
700014 even provides a pthread_cancel stub in libc, which
means the alternate __gthread_active_p below cannot be used
there. */
--
DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0904011954001.27704>