[Pkg-db-devel] Bug#441763: actually, no.
Zack Weinberg
zackw at panix.com
Thu Sep 13 23:47:01 UTC 2007
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
More information about the Pkg-db-devel
mailing list