reassign 441763 libc6 retitle 441763 /lib/libc.so.6 is missing several stub pthread interfaces thanks
Brian Carlson is seriously mistaken in all of his statements about this bug. It is possible to write correct C++ code that does not need any of the libraries that "g++" adds to the link, and in that case, using "gcc" to link it is fine. Especially when speaking of libraries, it may be highly desirable to avoid dragging libstdc++, libm, or libgcc_s into the runtime image. libpthread is not automatically added to the link by "g++", nor should it be. The only libraries "g++" adds to the link are, as mentioned above, libstdc++, libm, and libgcc_s. Most important, though - libdb-4.2.so should NOT be linked with libpthread, even though that would paper over this bug. Only libraries that create and use threads internally (to first order, libraries that call pthread_create themselves) should be linked with libpthread. libdb-4.2.so doesn't do that; all it is trying to do is use inter-thread *locking* when used by an application that does use threads. libc.so.6 provides stub versions of all the locking interfaces. They don't do anything, so they don't add overhead to single-threaded programs. When libpthread is present in the runtime image, its real locking interfaces supersede the stubs. This is not a triviality; if libpthread is dragged into the runtime image of a single-threaded program by unnecessary shared library dependencies, that program can suffer a severe slowdown, depending on what it is doing. (Ironically, one of the worst cases for this is C++ programs that make heavy use of std::string. I have measured actual runtime cost of 30% for some operations in Monotone.) The actual bug is that libc.so.6's stub interfaces are incomplete, and I am therefore reassigning this bug to libc6 and retitling it appropriately. zw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
