Bug#441763: actually, no.
reassign 441763 libdb4.2
thanks
On Thu, Sep 13, 2007 at 04:47:01PM -0700, Zack Weinberg wrote:
> 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.
>
What the fuck? Do you have in mind that you rely on a feature that does
not exists, and you are shouting because it does not exists?
libc.so.6's has NEVER provided such stub interfaces for the symbols you
want. Those symbols are in libpthread.so not in libc.so, so your library
must be linked with libpthread.so.
Your arguments about speed are pure bullshit. The fact is that the
symbols are not there, you can't compare something that works (maybe
slow, but that works) with something that you pretend faster but that
simply does not work.
Adding the stubs you want is something possible, but that needs to be
done upstream to not break binary compatibility. From the GNU libc side
this bug can only be considered as a wishlist.
Aurelien
PS: Monotone does not play DVD. That's bad because I have a script
that call monotone for that job, and it doesn't work. Please stay tuned,
I will open a bug report.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: