Date: Thu, 6 Oct 2005 13:15:43 -0400 From: Mikhail Teterin <Mikhail.Teterin@murex.com> To: Jason Evans <jasone@canonware.com> Cc: threads@freebsd.org, jim@corebsd.or.id Subject: Re: Non-threaded app dlopen-ing a thread-using library Message-ID: <200510061315.43692.Mikhail.Teterin@murex.com> In-Reply-To: <E602F495-DBE1-41E9-A0CB-6A872D575384@canonware.com> References: <200510050202.36730@aldan> <E602F495-DBE1-41E9-A0CB-6A872D575384@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
четвер 06 жовтень 2005 04:55, Jason Evans Ви написали: > On Oct 4, 2005, at 11:02 PM, Mikhail Teterin wrote: > > Do I need to make the executable itself multi-threaded -- just in case > > it needs to dlopen() a thread-using library, or is there a better way? > > As long as the dlopen()ed library is correctly linked, your app > doesn't need to explicitly link against the library's dependencies. > Dependencies should get pulled in after dlopen() as necessary, on the > fly, as a result of the dlopen()ed library's dependencies. What is the correct way to link a shared object, that uses threads? Using `-pthread' does not seem to change the output of ldd and a non-threaded executable is unable to dlopen() such an object. And for good reason -- the thread-implementation is decided at startup time, not at link-time, is not it? > There's nothing magical about a threaded app, as compared to a non- > threaded app. The first time a pthreads API is called, libpthread > initializes itself. It's fine if this happens as the result of > executing dlopen()ed code; the only issue is making sure that the > library dependencies are set up correctly. So, what happens, when a main executable calls some libc function directly, oblivious to the pthread-wrapper around it, that the dlopen-ed library's code is using? Thanks, -mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510061315.43692.Mikhail.Teterin>