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
Description: PGP signature