Hi, On Wed, Jan 23, 2019 at 05:52:19PM +0100, Amaury Pouly wrote: > Probably gcc-8 should be in conflict with binutils-x86-64-linux-gnu:i386 > because > of the following chain of events: > - install an unstable amd64 system > - enable multiarch i386 > - install gcc-8 > - install binutils-x86-64-linux-gnu:i386 > => This will (because of a conflict) uninstall binutils-x86-64-linux-gnu > Now the compiler is broken with this message: > /usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so: error loading plugin: > /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so: mauvaise classe ELF : > ELFCLASS64
What you describe is a real bug. When I designed the new binutils multiarch interface I failed to notice that you can load plugins into binutils. Thus we are missing an architecture constraint here. > This is because the plugin /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so > is installed by gcc-8 (it is an amd64 executable) but is loaded by ld. Since > we can independently install the 32-bit version of the binutils, now we > have a 32-bit executable loading a 64-bit library. I am not sure what is the > proper fix but clearly it should be impossible to install the 32-bit version > of binutils with the 64-bit version of gcc-8 because of this plugin. > This probably explains bug #916603 (with gcc-6 instead of gcc-8). I vaguely agree. I had hoped that you could mix and match gcc and binutils, but apparently this is not the case. While most users of binutils do not care about binutils' actual architecture, gcc clearly does. > Note that it may be strange to install binutils-x86-64-linux-gnu:i386 but > somehow APT decided to do it on its own at some point and I did not notice > so this can happen automatically. It's not as strange as you might think. It was actually intended to work that way and I think I tested it earlier. Maybe that was before the lto plugin became mandatory. Ultimately, this means that marking binutils-<triplet> M-A:foreign was wrong. It means that binutils plays the same role as ruby, perl, python and even make: you can load shared objects into it, but much of the time you don't. All of the other examples are M-A:allowed, so I guess binutils-<triplet> needs to become M-A:allowed as well. Given that gcc Depends on binutils, binutils is M-A:no, and binutils Depends: binutils-<triplet> without :any, the switch from M-A:foreign to M-A:allowed should fix this this bug, but at the same time it would break a fair number of use cases. We specifically have binutils-for-host to allow using foreign binutils. Likely binutils-for-host should Depends: binutils-<triplet>:any then. On the flip side, that means that whenever you need plugins, you cannot use binutils-for-host. Now marking anything M-A:allowed is basically irreversible, because people are going to use :any and all those deps break when removing M-A:allowed. Therefore we should think hard about whether this is the right route. I've added debian-cross@l.d.o to Cc to elicit some feedback. Failing that, I'll prepare a patch for doing the M-A:allowed thingy. Helmut
