From owner-freebsd-ports@FreeBSD.ORG Wed Apr 1 23:18:38 2009 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2904106566C for ; Wed, 1 Apr 2009 23:18:38 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6E23C8FC0A for ; Wed, 1 Apr 2009 23:18:38 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Lp9hd-0002mY-6K; Thu, 02 Apr 2009 03:18:37 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 9A55E12764; Thu, 2 Apr 2009 03:18:40 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 5298B10883C; Thu, 2 Apr 2009 03:18:31 +0400 (MSD) Date: Thu, 2 Apr 2009 03:18:31 +0400 From: Dmitry Marakasov To: freebsd-ports@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20090401231831.GS1964@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: -pthread propagation X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 23:18:39 -0000 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? 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. 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: 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. 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? -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru