Date: Fri, 12 Sep 2008 09:09:00 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Barry Andrews <titanandrews@gmail.com> Cc: Daniel Eischen <deischen@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: loading multi threaded library into executable enabled for single thread Message-ID: <20080912160900.GC60094@icarus.home.lan> In-Reply-To: <eda4c18b0809120855s8867995m7834d26fe79866b1@mail.gmail.com> References: <eda4c18b0809111206t6438f87dmb8fab0db939c9980@mail.gmail.com> <Pine.GSO.4.64.0809111620340.13959@sea.ntplx.net> <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> <eda4c18b0809120626u48fbe5e2pdf7147d71d1f8def@mail.gmail.com> <20080912135110.GA57637@icarus.home.lan> <48CA8402.5040207@gmail.com> <20080912154520.GA60094@icarus.home.lan> <eda4c18b0809120855s8867995m7834d26fe79866b1@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 12, 2008 at 11:55:01AM -0400, Barry Andrews wrote: > 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. This really isn't a "FreeBSD problem", as the same sort of issue plagues other operating systems. When it comes to threading, you want *everything* threaded as much as possible -- mix-matching usually does not work. The only OS I have seen where that kind of environment works reliably is Solaris. I still feel threading is "too new" of a technology on UNIX. Your options as I see them: 1) Require your users to ensure they have a threaded TCL installation, and do not promise support in the case they try to use your library on a non-threaded installation, 1) Provide two versions of your library -- a threaded and non-threaded version. This may be impractical for performance reasons, 3) Require LD_PRELOAD, which is ugly, agreed. I think those are pretty much the only options you have at this point. Not a great set, I know, but it's reality. > On Fri, Sep 12, 2008 at 11:45 AM, Jeremy Chadwick <koitsu@freebsd.org>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 <koitsu@freebsd.org> > > 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 | > > >>>> > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> freebsd-hackers@freebsd.org mailing list > > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > >>> To unsubscribe, send any mail to " > > freebsd-hackers-unsubscribe@freebsd.org" > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > freebsd-hackers@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > To unsubscribe, send any mail to " > > freebsd-hackers-unsubscribe@freebsd.org" > > > > -- > > | 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 | > > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- | 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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080912160900.GC60094>