From owner-freebsd-threads@FreeBSD.ORG Mon Mar 3 02:59:14 2008 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EAD4106566B for ; Mon, 3 Mar 2008 02:59:14 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmmtao102.cox.net (eastrmmtao102.cox.net [68.230.240.8]) by mx1.freebsd.org (Postfix) with ESMTP id E04918FC24 for ; Mon, 3 Mar 2008 02:59:13 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmmtao102.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080303025914.TSRC19740.eastrmmtao102.cox.net@eastrmimpo03.cox.net>; Sun, 2 Mar 2008 21:59:14 -0500 Received: from mezz.mezzweb.com ([24.255.149.218]) by eastrmimpo03.cox.net with bizsmtp id wStZ1Y0064iy4EG0000000; Sun, 02 Mar 2008 21:53:33 -0500 Date: Sun, 02 Mar 2008 21:00:38 -0600 To: "John E Hein" From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <18378.55323.480165.918523@gromit.timing.com> <18379.24676.854429.480513@gromit.timing.com> Content-Transfer-Encoding: Quoted-Printable Message-ID: In-Reply-To: <18379.24676.854429.480513@gromit.timing.com> User-Agent: Opera Mail/9.26 (Linux) Cc: threads@freebsd.org Subject: Re: running threaded tasks in dynamically linked objects from a non-threaded app X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 02:59:14 -0000 On Sun, 02 Mar 2008 20:20:20 -0600, John E Hein wrote= : > Jeremy Messenger wrote at 11:33 -0600 on Mar 2, 2008: > > On Sun, 02 Mar 2008 10:38:51 -0600, John E Hein = = > wrote: > > > I am having some issues with an application that uses... > > > [1] perl to run test scripts > > > [2] with eventually call modules in C modules > > > [3] which link with a lib that contains pthread* references. > > > > > > When the tests run, one gets undefined references to pthread call= s > > > from the run-time linker. > > > > > > [1] the perl port was not built WITH_THREADS=3Dyes (non-threaded > > > is the default) > > > [3] this lib was built with -pthread, but this does not contain > > > an explicit dependency on any threading library. That's > > > how our -pthread works (so one can decide at the time an > > > application is linked which threading lib to use) > > > > > > workarounds: > > > - LD_PRELOAD=3D/usr/lib/libthr.so (or libpthread.so if desired) > > > - require perl to be built WITH_THREADS=3Dyes for > > > users of this application > > > - build the lib in [3] with -lthr or -lpthread. This > > > can break if perl in built WITH_THREADS=3Dyes and > > > the threading libs in [1] and [3] don't match. > > > > > > These all have weaknesses in one facet or another. > > > Are there any different solutions? > > > > Are you using FreeBSD 6.x or below? I think it has been fixed in = > FreeBSD > > 7.x and above with GCC 4.x. I only have tested it with Ruby. > > I had tried it first with 6.x. > > After your reply, I ran off to try it on 7.x. > It did not have undefined references. > > The difference seems to be that the lib (in [3]) now shows an > explicit dependency on libthr.so.3. So -pthread behaves differently > in 6.x vs. 7.x in this regard. > > > _What_, specifically, has been "fixed" and how? I personal don't really understand why or how problem in FreeBSD 6.x/GCC= = 3.x. Someone has suggested me that it's GCC 4.x that help this issue in = = FreeBSD 7.x and above. There is still one more problem with -pthread = stuff, bland has a simple C test and it will crashing. I can dig up in m= y = Inbox if anyone want this simple C test and a bit explain by bland. In past, I wrestled with ruby for -pthread stuff. I have added the = -phtread ruby in build even with threads option disable to solve other = ports problem. I had to keep remind to someone that who touch Ruby port = = when they think that add -pthread with threads option disable is = incorrect. :-) http://lists.freebsd.org/pipermail/cvs-ports/2005-February/058420.html http://lists.freebsd.org/pipermail/cvs-ports/2006-May/095213.html There is one problem with have ruby compiles with -pthread: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D81464 But all of that have been solved in FreeBSD 7.x/GCC 4.x, so I am thinkin= g = about ask Ruby maintainer to see if he can get -pthread only compile on = = FreeBSD 6.x and below. The -pthread should be no longer need in FreeBSD = = 7.x and above for Ruby unless enable with threads option. > And what happens if one does something like this on 7.x... > > gcc -pthread -shared foo.c -o foo.so (assuming the default pthread = lib > is libthr) > gcc -lkse bar.c foo.so -o bar > > ... where both bar.c does some pthread* calls and foo.c does some > pthread* calls. Is the libthr linking of foo.so overridden by libkse > of the main app in bar.c so no conflicting threading library calls > occur? In other words does the whole app use libkse calls due to the > weak refs in all libs involved (libc, libthr, libkse)? This sounds > perfectly reasonable, so I'm just talking this through. I am curious > what the problem was with gcc 3.2 / freebsd 6.x, however. > > > So, if this all does the right thing in gcc 4.2, it sounds like a > reasonable workaround is to compile my app with ports/lang/gcc42 on 6.= x No idea, I don't have answer for that. I am going to let people that who= = understand this problem(s) to answer. :-) Cheers, Mezz -- = mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org