[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 09, 2014 at 09:55:06PM +0100, Kurt Roeckx wrote:
> On Thu, Jan 09, 2014 at 07:20:40PM +0000, Colin Watson wrote:
> > 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?

Hmm.  You should probably drop cpp on general principles, because as far
as I can see libtool doesn't call it directly, so there should also be
no reason for it to depend on it directly.  file and autotools-dev are
Multi-Arch: foreign so are not problematic.  libc6-dev, well, it's
Multi-Arch: same and anyone doing cross-building will have that
installed on all relevant architectures anyway, so who cares.  That
leaves gcc and I suppose you could bend the rules there.

Replacing the dependencies with build-essential will make no difference;
it has no Multi-Arch field, so it'll effectively just pass through the
architecture-ness of dependencies - that is, depending on gcc via
build-essential is no different from depending on it directly for this
purpose.  The only way you could dodge this would be to drop the
dependency on gcc entirely, along with cpp.  I agree that that would
simplify matters, as it would then be safe to install libtool:<host>.

It would be quite a delicate compromise.  If you ever needed to add a
dependency (e.g. "gcc (>= 4.9)", hypothetically), you could be out of
luck; it would really require a comment in the control file to make sure
that your future self or your successor maintainers didn't forget about
the arrangement and break things.

It would also be less good for anyone doing cross-building other than in
a clean chroot.  Since you can only have one libtool package installed
and you're proposing not to have it be Multi-Arch: foreign, there'd be a
good chance of conflicts (e.g. the effects of "apt-get install
dh-autoreconf" would have to be reversed before cross-building something
that build-depends on libtool, which could make local tests more
complicated).  I know that in general cross-builds work better in clean
chroots anyway, but all other things being equal I'd like to have as few
possible causes of package conflicts as possible; it just seems safer.
At present the autotools toolchain is pretty much all Multi-Arch:
foreign, which I've found to be rather convenient.

So, yes, I think your approach might work; but I think I'd be inclined
to rank it slightly below your previous option 1, because it seems
rather fragile and I can see at least one potential practical problem
with it, even though it would probably fix cross-building.  Does that
make sense to you?

Colin Watson                                       [cjwatson@debian.org]

Reply to: