Rainer Orth wrote: > As you can see, without -G, an executable is linked with -lthread, while > with -G a shared object is not. > > In the Studio 12.1 cc manpage, there's nothing justifying this > difference in behavior, while the 12.2ex manpage has > > Note that when compiling with -G,neither -ltread nor > -lpthread are automatically included by -mt=yes. You > will need to explicitly list these libraries when > building a shared library. > > What's the reason for this difference, or are you just documenting an > existing bug? This seems rather unintuitive and confusing.
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. 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. 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. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ tools-compilers mailing list [email protected]
