libtool-bin requires a compiler for proper operation. In earlier times,
there was only the libtool binary package, which still depends on gcc |
c-compiler. Then we split out /usr/bin/libtool to libtool-bin and had it
depend on libtool thus inheriting all dependencies, at least we thought.
What we forgot is that libtool became Multi-Arch: foreign.  Thus
installing libtool-bin:arch1 with gcc:arch2 is considered ok.
Unfortunately that doesn't work well as /usr/bin/libtool expects
gcc/g++/ld to match its own architecture.

The trivial solution to this problem is adding an explicit dependency on
gcc | c-compiler to libtool-bin.

I note though that after adding that dependency, libtool-bin will
effectively become unusable to cross building, because its gcc:hostarch
dependency will not be satisfiable.  In a distant future, we want it to
depend on gcc-for-host instead and thus allow cross compilers to be
used. Until that becomes reality, the dependency on gcc will remind us
that cross building anything that Build-Depends on libtool-bin will be a
fruitless exercise.

Helmut

We actually have 67 packages that build-depend on libtool-bin?

Really nothing should be build-depending on that.  I consider it a
bug that anything uses it.  That should generate libtool by
running configure.

And that libtool is configured for the arch of the package, it's
not usable for any other arch.


Kurt

It's hard to disagree with that. We know that it is a kludge. Though it
is a kludge that makes those 67 source packages work and it is a kludge
that makes recognizing the size of the problem easy.

Still, adding that dependency will turn cross build failures into
dependency-satisfaction failures thus saving lots of brain cycles.

Helmut

Hi Helmut,


Revisiting this old bug.

    I note though that after adding that dependency, libtool-bin will
    effectively become unusable to cross building, because its gcc:hostarch
    dependency will not be satisfiable.  In a distant future, we want it to
    depend on gcc-for-host instead and thus allow cross compilers to be
    used. Until that becomes reality, the dependency on gcc will remind us
    that cross building anything that Build-Depends on libtool-bin will be a
    fruitless exercise.

What in your opinion should be done now?

Regards
Alastair

Hi Alastair,

Thank you for raising this. There are several non-obvious angles here.

One angle is an aspect from my initial report:

| I note though that after adding that dependency, libtool-bin will
| effectively become unusable to cross building, because its gcc:hostarch
| dependency will not be satisfiable.  In a distant future, we want it to
| depend on gcc-for-host instead and thus allow cross compilers to be
| used. Until that becomes reality, the dependency on gcc will remind us
| that cross building anything that Build-Depends on libtool-bin will be a
| fruitless exercise.

That distant future mentioned there is right now. We do have
gcc-for-host since trixie. Beware though that for using it, we must
patch libtool to actually use a triplet-prefixed gcc. It presently uses
a bare gcc.

Practically speaking, due to using the bare gcc, libtool-bin is unusable
for cross compilation right now. Tightening that dependency on gcc
merely prevents us from attempting a build that would fail anyway.
Considerable effort has gone into moving packages from libtool-bin.

Keep in mind what Kurt said:

| Really nothing should be build-depending on that.  I consider it a
| bug that anything uses it.  That should generate libtool by
| running configure.

We're up to 70 packages a few of which have patches. At some point we
should simply delete the package and have everyone libtoolize instead.

So my current understanding is that the tightened dependency does no
harm beyond what is broken already.

Helmut