Non-threaded app dlopen-ing a thread-using library

[Mikhail Teterin]

четвер 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