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

Re: Bug#682045: libtool: please mark libtool multi-arch: allowed

On Thu, Jan 02, 2014 at 06:14:07PM +0000, Dimitri John Ledkov wrote:
> The correct solution is for libtool package to be marked as
> "multi-arch: allowed" without splitting this tiny package into two
> even smaller packages.

This analysis makes sense as far as it goes, but the problem with it is
that it neglects any consideration of libtool's dependencies.  As I
discovered today, it totally hoses cross-building as a result.  If
libtool is Multi-Arch: allowed, then everything that build-depends on it
gets libtool:<host> (i.e. the architecture you're building for).  Now,
that initially seems like what you want, because it gives you the
host-architecture /usr/bin/libtool.  But it also pulls in
host-architecture dependencies of libtool, which include gcc and cpp,
where we must have the build-architecture versions (i.e. the
architecture you're building on).  Note that :native is only legal in
build-dependencies, not in ordinary Depends, so it cannot be used to
work around this.

As a result of this, today in Ubuntu (which has the M-A: allowed change)
a large pile of stuff fails to cross-build when it used to work.  This
is bad and I plan to revert it to something closer to the state in
Debian.  I strongly suggest not introducing the same breakage in Debian.

We could maybe figure out some answer to this, but it might well mean
annotating lots of libtool reverse-build-dependencies, possibly fiddling
with dh-autoreconf, or possibly doing very delicate things to the
compiler's multiarch annotations.  All this seems vastly excessive to
cope with the case of packages that are using libtool in the *wrong way*
to start with, that is, relying on /usr/bin/libtool rather than
generating one in configure.  Let's not vastly multiply up the effort
required to support cross-building in the cause of improving
cross-building support!

Apparently, though, quite a few packages do fail to build with
/usr/bin/libtool split out.  I don't have numbers yet - Matthias said he
was going to summarise.  Still, I think this will be easier to fix than
trying to get an M-A: allowed libtool to work properly.

If you weren't one of the people in the "thinking extremely hard about
multiarch" BOF at DebConf, note that Multi-Arch: foreign denotes a point
in the dependency graph where you're allowed to switch architectures,
Multi-Arch: allowed denotes such a point if and only if the incoming
dependency is annotated with :any, and otherwise you may not switch
architectures; this holds even when you're going through an
Architecture: all package, so you're allowed to do this:

  Package: a
  Architecture: i386
  Depends: b

  Package: b
  Architecture: all
  Depends: c

  Package: c
  Architecture: i386

... but not this:

  Package: a
  Architecture: i386
  Depends: b

  Package: b
  Architecture: all
  Depends: c

  Package: c
  Architecture: amd64

Bearing that in mind, let's go back to Kurt's options in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682045#22, elaborated a

  1: split most of libtool out to libtool-dev (Architecture: all, M-A:
     foreign); leave /usr/bin/libtool in libtool; make libtool depend on

    Workable for cross-building.

    Nobody needs to change; native builds will remain as before, while
    cross-builds will get libtool:<host>, libtool-dev, and
    build-architecture dependencies of libtool-dev.

    In this case, it is vitally important to make sure that libtool-dev
    is M-A: foreign as well as Architecture: all and that all libtool's
    existing dependencies (with the possible exception of libc-dev) are
    moved to libtool-dev; this will mean that apt will prefer the build
    architecture for these dependencies even when libtool is being
    installed from the host architecture.

    libtool could either be M-A: none or allowed.  I'd be inclined to go
    with none, just because I can't see a clear reason to want the
    build-architecture version at all and it seems like a bit of a
    footgun, but I think either would technically work.

  2.1: split /usr/bin/libtool out to libtool-bin (M-A: none or maybe
       allowed); make libtool depend on libtool-bin

    It seems to be difficult to make this work properly with
    cross-building.  The two choices for libtool are to mark it M-A:
    allowed or M-A: foreign (or leave it unset, in which case you
    basically get one or the other behaviour depending on #666772, so
    let's ignore that).  With M-A: allowed, there is nowhere to put the
    compiler dependencies that will be resolved for the build
    architecture, unless you declare Build-Depends: libtool:any; but
    then you'll get libtool-bin:<build> rather than libtool-bin:<host>,
    so this is futile.  With M-A: foreign, you will similarly get
    libtool-bin:<build> rather than libtool-bin:<host>.

    It might be possible, though, to have libtool M-A: foreign and
    Depends: libtool-bin:any, and then anyone who needed
    libtool-bin:<host> could add an explicit Build-Depends: libtool-bin.
    This ends up being no-change for native builds, and equivalent to
    2.2 for cross-builds.

  2.2: split /usr/bin/libtool out to libtool-bin (M-A: none or maybe
       allowed); no dependency from libtool to libtool-bin

    Workable for cross-building.

    Some packages using /usr/bin/libtool need to change to add a
    build-dependency, for both native and cross builds.

  3: mark libtool M-A: allowed

    Theoretically workable for cross-building, but probably requires
    changing huge numbers of reverse-build-dependencies in order not to
    regress that.

  4: drop /usr/bin/libtool; mark libtool Architecture: all, M-A: foreign

    Workable for cross-building.

    More correct in some sense, but some packages using /usr/bin/libtool
    need to have their build system re-engineered; from the point of
    view of effort this is strictly inferior to 2.2 (which affects the
    same packages but only requires a one-line change to their

So, ranking these from least to most effort required elsewhere in the
archive, we seem to have:

  2.1 (maybe)

Assuming the Depends: libtool-bin:any trick works, 2.1 is less effort
than 2.2, but it's a good deal more complicated.

Overall, I would therefore prefer option 1 (not the option I expected to
prefer when I started analysing this!), because as far as I can see it
will unblock cross-building for both packages that need /usr/bin/libtool
and those that don't, without requiring any changes to those packages,
and it won't affect native building either way.

Reasoning about multiarch can be hard work and I'm running low on
coffee.  Would anyone like to pick holes in this analysis?

Kurt, if I've persuaded you that option 1 is best, I'd be happy to run a
test cross-build against some reasonable subset of packages to see how
it performs, especially if anyone can think of an example package that's
wedded to /usr/bin/libtool.  I think it's clear that this option would
have no effect on native builds and doesn't require extensive testing


Colin Watson                                       [cjwatson@ubuntu.com]

Reply to: