Date: Sun, 02 Mar 2008 21:00:38 -0600 From: "Jeremy Messenger" <mezz7@cox.net> To: "John E Hein" <jhein@timing.com> Cc: threads@freebsd.org Subject: Re: running threaded tasks in dynamically linked objects from a non-threaded app Message-ID: <op.t7e6ncry9aq2h7@mezz.mezzweb.com> In-Reply-To: <18379.24676.854429.480513@gromit.timing.com> References: <18378.55323.480165.918523@gromit.timing.com> <op.t7egd9di9aq2h7@mezz.mezzweb.com> <18379.24676.854429.480513@gromit.timing.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 02 Mar 2008 20:20:20 -0600, John E Hein <jhein@timing.com> wrote= : > Jeremy Messenger wrote at 11:33 -0600 on Mar 2, 2008: > > On Sun, 02 Mar 2008 10:38:51 -0600, John E Hein <jhein@timing.com> = = > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.t7e6ncry9aq2h7>