[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#920286: gcc-8: Missing conflict/break with binutils-x86-64-linux-gnu:i386 can lead to broken compiler



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


Reply to: