running threaded tasks in dynamically linked objects from a non-threaded app

[Jeremy Messenger]

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>  
> 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 calls
>  > > from the run-time linker.
>  > >
>  > > [1] the perl port was not built WITH_THREADS=yes (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=/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 [3] with -lthr or -lpthread.  This
>  > >    can break if perl in built WITH_THREADS=yes 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 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  
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=81464

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. :-)

Cheers,
Mezz


-- 
mezz7 at cox.net  -  mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome at FreeBSD.org