Yes, the exe is tclsh. I understand that linking tclsh with libpthread is what would work. However this is very impractical. A user of my library shouldn't have to rebuild their tclsh to match my library specs. Another option would be to ship tclsh with my lib, but that also is a little weird. It seems like the only somewhat practical option I have is to use LD_PRELOAD, which is also weird but better than nothing.
On Fri, Sep 12, 2008 at 11:45 AM, Jeremy Chadwick <[EMAIL PROTECTED]>wrote: > On Fri, Sep 12, 2008 at 11:00:18AM -0400, Barry Andrews wrote: > > Thanks for the links! But I'm not sure what any of this has to do with > > this particular issue. I have an exe that does not use threads that > > loads a lib that is linked with libpthread. Why does different threading > > implementations affect what I am seeing here? Is there no way for this > > to work in FreeBSD v5.5? Why would this go away if I upgraded to 6.x or > > better? > > You're confusing me. Earlier you said: > > >>>>>>> I have a multi-threaded library that is linked against libpthread. > >>>>>>> When I > >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, > > So what is "the exe?" Are you referring to tclsh? If so, you need to > rebuild tclsh from source to link with libpthread. If not, you need to > contact whoever provided the binary and ask them to rebuild it from > source. > > Additionally, please ensure that the tclsh binary is linked to the same > version of libpthread library as your own library. You want to make > sure they're both built and linked on the same machine (from the same > source code) if possible; the simple ".so.X" versioning method works > great for major changes, but there are often minor changes that don't > result in "X" being increased. > > I'm getting the impression that the tclsh binary you have was not built > on the same machine / from the same source as what your library (the one > linked with libpthread) was. > > > Jeremy Chadwick wrote: > >> On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote: > >> > >>> I don't understand. If it was not broken, then why did it change in > later > >>> FreeBSD versions? > >>> > >> > >> I should be more explicit: the threading library and implementations > >> have changed over time. There was libc_r, then there was libthr, then > >> there was libkse. This is what we call "evolution". :-) > >> > >> http://www.unobvious.com/bsd/freebsd-threads.html > >> http://kerneltrap.org/node/624 > >> http://www.freebsd.org/kse/ > >> > >> The gcc -pthread flag is still there on present-day FreeBSD (6 through > >> HEAD), and *should* be used. You can choose not to use it but you must > >> ensure during linktime that you explicitly link to -lpthread. > >> > >> > >>> On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick <[EMAIL PROTECTED]> > wrote: > >>> > >>> > >>>> On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: > >>>> > >>>>> Do you know if this is documented in Release Notes or Known Issues or > >>>>> somewhere? > >>>>> > >>>> Why would it be an "issue"? gcc -pthread and libpthread linking is > >>>> documented pretty much everywhere on the web. There isn't anything > >>>> broken about it, it's how it's done on older FreeBSD. > >>>> > >>>> Note that all of this has significantly changed in later FreeBSD > >>>> versions, and that the 5.x series was deprecated a very long time ago. > >>>> > >>>> > >>>>>> On Thu, 11 Sep 2008, Barry Andrews wrote: > >>>>>> > >>>>>> > >>>>>>> Hi All, > >>>>>>> > >>>>>>> I have a multi-threaded library that is linked against libpthread. > >>>>>>> When I > >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, > >>>>>>> "Recurse on > >>>>>>> private mutex". and crash. I understand that I can have this issue > >>>>>>> when the > >>>>>>> executable is not linked against libpthread but one of the loaded > >>>>>>> libs is. > >>>>>>> Basically, it thinks it's in single threaded mode. > >>>>>>> > >>>>>> This must be an older version of FreeBSD. I think you must > >>>>>> link your application (tclsh or whatever) against libpthread > >>>>>> in order for this to work. The libc functions won't get properly > >>>>>> overloaded by their equivalents in libpthread unless you do > >>>>>> this. > >>>>>> > >>>> -- > >>>> | Jeremy Chadwick jdc at parodius.com| > >>>> | Parodius Networking http://www.parodius.com/| > >>>> | UNIX Systems Administrator Mountain View, CA, USA | > >>>> | Making life hard for others since 1977. PGP: 4BD6C0CB | > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> [email protected] mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >>> To unsubscribe, send any mail to " > [EMAIL PROTECTED]" > >>> > >> > >> > > > > _______________________________________________ > > [email protected] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > [EMAIL PROTECTED]" > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
