[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