On Sat, Feb 16, 2008 at 10:58:13AM +0000, Pierre Habouzit wrote: > I absolutely don't understand how that can be true. I mean it doesn't > make sense, ktorrent gets the symbol from the libc6, and it just emits > an undefined symbol because qt3 provides it at the time, there is no way > it gets it another way. > > So I'll try to redo a proper test where I'm actually really sure of what I > have during the build instead of probable speculations.
Okay, so for the others, here is what happens for real:
* the extern inlines from sys/stat.h are just gone, and that's just
normal in fact.
* /usr/lib/libc.so is a linker script that pulls /lib/libc-2.7.so
_and_ /usr/lib/libc_nonshared.a.
* the latter defines stat64 and friends as weak-symbols and alises to
__xstat64 and friends.
That's how when you link something that uses fstat64 it finds the
symbol at link time, letting you the possibility to override it with
your own implementation.
The fact that the extern inlines were used at some point in the past
_was_ a bug, and let qt3 divert those, which should have not happened in
the first place. Sadly, when you link against qt3, it picks those
symbols because it will always prefer symbols from a shared lib than
from the .a IIRC, or it's due to the link order, anyways, it's not
relevant.
So with this new information, I'd say that the safest way is to re-add
manually (I heard Modestas has a patch for that) the symbols to qt3.
It's not pretty, but qt3 will disappear eventually, and it's not a
problem to hack it that way, whereas reenabling the patch in the libc
will concern more and more symbols with time, and has good chances to
become an issue. I'm still not in favor of it.
We should still look in the archive if other libraries have the
symbols and deal on a per case basis. It seems c++ libraries are the one
affected, C ones usually arent as extern inline has a different meaning
in C (especially in GNU C 89).
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgpHCNccGvqje.pgp
Description: PGP signature
