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

[John E Hein]

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?


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