Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #63656 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#920286: gcc-8: Missing conflict/break with binutils-x86-64-linux-gnu:i386 can lead to broken compiler Helmut Grohne <helmut@subdivi.de> - 2019-03-19 15:50 +0100
    Bug#920286: gcc-8: Missing conflict/break with binutils-x86-64-linux-gnu:i386 can lead to broken compiler Ben Hutchings <ben@decadent.org.uk> - 2019-03-20 02:10 +0100

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

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jan 24, 2019 at 04:38:19PM +0100, Helmut Grohne wrote:
> 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.

You can find the patch for binutils attached. binutils-<triplet> will
become Multi-Arch: allowed. With this patch applied there are the
following ways to depend on binutils:

 A Source package.
   A.A You want binutils for the host architecture -> binutils-for-host
   A.A You want binutils for the build architecture -> binutils-for-build
 B Binary package of architecture $ARCH.
   B.A You want binutils targeting the $ARCH.
     B.A.A Your package contains a plugin to load into binutils ->
           binutils-$ARCH
     B.A.B No plugin -> binutils-$ARCH:any
   B.B You want binutils targeting some executable architecture.
     B.B.A Your package contains a plugin to load into binutils ->
           binutils
     B.B.B No plugin -> binutils-for-build

In #895251, I requested that gcc use triplet-prefixed tools to allow
coinstalling binutils. It also made the architecture of binutils opaque
(which is what this bug is about). After causing repeated problems, the
relevant change was finally reverted via #915194. Now gcc uses
unprefixed tools again. But it still prefers prefixed tools in
/usr/<triplet> (which is what this bug is about). We'll should change
that using triplet-prefixed tools explicitly at some point.  gcc-8
presently Depends on "binutils". gcc-8-<target> will have to Depends
binutils-<target> without a :any. With the patch, binutils will Depends:
binutils-<triplet> without :any, so using gcc-8:amd64 with
binutils-x86-64-linux-gnu:i386 will no longer be possible. So on the gcc
side, the attached patch will work.

src:arch-test uses binutils-<triplet>, but it is Architecure: all, so it
pretty much doesn't matter whether the dependencies are annotated or
not.

src:cross-toolchain-base{,-port} conflicts with a number of
binutils-<triplet>. That will continue to work.

src:gcc-8-cross (and similar packages) Build-Depends binutils-<triplet>.
The binutils patch will render these dependencies cross-unsatisfiable.
They will need to be annotated :any or switched to binutils-for-host if
we want to cross build gcc-8-cross. Matthias, will you handle these?

src:linux Build-Depends binutils-<triplet>. The binutils patch will
render these dependencies cross-unsatisfiable. They will need to be
switched to binutils-for-host or annotated with :any (after checking
that it doesn't use plugins). Maintainers Cced.

So the attached patch will break cross building of gcc and linux.  It
won't break any native stuff and it'll fix the bug at hand.

Helmut

[toc] | [next] | [standalone]

#63659

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2019-03-19 at 15:41 +0100, Helmut Grohne wrote:
[...]
> src:linux Build-Depends binutils-<triplet>. The binutils patch will
> render these dependencies cross-unsatisfiable. They will need to be
> switched to binutils-for-host or annotated with :any (after checking
> that it doesn't use plugins). Maintainers Cced.

We only do that for hppa, as the standard gcc-8 & binutils packages
only support 32-bit code and we need to build 64-bit kernels there.  We
don't use plugins for binutils.

Ben.

> So the attached patch will break cross building of gcc and linux.  It
> won't break any native stuff and it'll fix the bug at hand.
> 
> Helmut
-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web