running threaded tasks in dynamically linked objects from a
mezz7 at cox.net
Mon Mar 3 02:59:14 UTC 2008
On Sun, 02 Mar 2008 20:20:20 -0600, John E Hein <jhein at 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 at timing.com>
> > > I am having some issues with an application that uses...
> > >  perl to run test scripts
> > >  with eventually call modules in C modules
> > >  which link with a lib that contains pthread* references.
> > >
> > > When the tests run, one gets undefined references to pthread calls
> > > from the run-time linker.
> > >
> > >  the perl port was not built WITH_THREADS=yes (non-threaded
> > > is the default)
> > >  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=/usr/lib/libthr.so (or libpthread.so if desired)
> > > - require perl to be built WITH_THREADS=yes for
> > > users of this application
> > > - build the lib in  with -lthr or -lpthread. This
> > > can break if perl in built WITH_THREADS=yes and
> > > the threading libs in  and  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
> > 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 ) 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 my
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
There is one problem with have ruby compiles with -pthread:
But all of that have been solved in FreeBSD 7.x/GCC 4.x, so I am thinking
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. :-)
mezz7 at cox.net - mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gnome at FreeBSD.org
More information about the freebsd-threads