James Carlson <[email protected]> writes:
> The reason it is (or at least was) like this was that it's possible to
> build shared libraries that work with threads when the application uses
> threads and still work fine when the application is not multi-threaded.
>
> The way this worked was that libc had weak threads stubs in it. If you
> tried to take a mutex lock from inside your library, and only libc was
> present, it would link fine, but the call would do nothing but return
> success. If the application that uses your library also linked with one
> of the threads libraries, that would bind instead of the libc stubs, and
> you'd get the real function instead.
Thanks, I recall that now that you mention it.
> That way, a library could be "ready" for threads if the containing
> application actually used threads, and still work fine if the parent
> didn't. If you were building such a shared library, you'd want -G but
> you would *not* want automatic binding with any threads library, because
> that's something for the main application to decide.
... though you'd have been able to decide that by compiling with -mt
(which would define -D_REENTRANT as required), but *not* linking with it.
> That's all changed now that the threads libraries have been folded into
> libc. There's no such thing as purely unthreaded any more -- just
> multithreaded applications that happen to have only one thread -- and
> all of the calls are "live" all of the time.
Right. I think I'm going for linking -lpthread and/or -lthread with
-pthread/-threads -shared in GCC even on Solaris 8 and 9 and add
-L/usr/lib/lwp -R/usr/lib/lwp on Solaris 8. The alternative of having
the user specify all that (and spread the necessary knowledge all over
the GCC tree) is just unacceptable.
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
_______________________________________________
tools-compilers mailing list
[email protected]
