On Tue, 24 Jul 2007 03:26:14 +0100 Wookey <wookey@aleph1.co.uk> wrote: > My testing machine has become rather broken. The core of the issue > seem to be that the new glibc6-2.6 conflicts with > binutils-arm-linux-gnu: Zumbi: we need to include a patch for binutils to solve this. /usr/lib64/libiberty.a I can't see where this path is constructed. :-( There is a bigger problem here too - what was decided about /usr/lib64 ? /usr/lib64 -> lib Basically, I don't think our binutils-foo builds should be allowing any installation into /usr/lib64, just /usr/lib/ and if processes want to find /usr/lib64/foo the symlink will do the job for us. > wookey@eisluft:/var/cache/apt/archives$ sudo dpkg -i libc6_2.6-2_amd64.deb > (Reading database ... 105532 files and directories currently installed.) > Preparing to replace libc6 2.5-9 (using libc6_2.6-2_amd64.deb) ... > Unpacking replacement libc6 ... > dpkg: error processing libc6_2.6-2_amd64.deb (--install): > trying to overwrite /usr/lib64', which is also in package binutils-arm-linux-gnu > Errors were encountered while processing: > libc6_2.6-2_amd64.deb > > Not quite sure what is going on, but it looks like something we need > to attend to in our toolchain builds. IMHO binutils should not be putting anything into /usr/lib64 For now, the fix is presumably dpkg --force-all to restore a working system. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpIJzwOWNoIk.pgp
Description: PGP signature