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

[Kurt Roeckx <kurt@roeckx.be>]

On Thu, Jan 09, 2014 at 07:20:40PM +0000, Colin Watson wrote:
> 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.

I'm wondering why I have:
Depends: gcc | c-compiler, cpp, libc6-dev | libc-dev, file, autotools-dev

The file part makes sense since libtool will call it.

The autotools-dev is because /usr/share/libtool/config/config.*
points to the files from autotools-dev.

But the other things are ussually installed as part of
build-essential, and I don't see the real need for libtool
to Depend on them.  libtool isn't going to work without them,
but I'm not sure it's libtool that should be pulling in those
dependencies.  Maybe I should replace them by build-essential?
Will that change the result of any of this?


Kurt