On Tue 10 Apr, Philip Blundell wrote: > Argh! When I converted the autobuilders to run chrooted rather than in the > host filesystem, I forgot to copy the fixed `ld' into the chroot directory. > I guess this is why Tor has been seeing new broken packages get built.
I'm about to start doing a new RiscPC release and a new LART release, working from the current archive. So I want to make sure this problem is dealt with so people get a system where half the progs don't segfault for no good reason. My understanding is this: > The bug actually occurs if a binary was compiled under glibc 2.2 and uses > shared libraries that were compiled under glibc 2.1 - when those libraries > are themselves recompiled against glibc 2.2, the binary will start to > crash. And there are some unkown, but quite large (maybe hundreds) of packages afflicted. Just rebuilding the lot probably isn't practical, but how long before the system shakes out and this goes away. Weeks, months, years? I assume that an afflicated package only gets rebuilt when it is updated in the normal way of things. Presumably this prob started sometime in 2.2r2? Phil has provided a fix (it a good job someone understands all this stuff!) with an /etc/ls.so.preload that fettles things (does it fix up the binary?). Which I understand to be effective. How should this be installed in the system - should it be added to some base package - which one? ldso? When might we be able to safely remove it again? Seems to me this quite a serious cock-up and its worth putting some effort into transparently fixing it. Can we start doing rebuilds of the broken stuff for example (I'll do it if someone gives me a clue), or would this mean bumping the version numbers of half the distribution and doing hundreds of NMUs which might be more trouble than the problem? Advice welcome. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
