Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Helmut Grohne <helmut@subdivi.de>]

Hi Bastian,

On Wed, Mar 06, 2024 at 07:52:09AM +0100, Bastian Blank wrote:
> On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> > The problem arises in the reverse sense. If a file does not exist in
> > one, it is searched in the second and erroneously may be found. That may
> > make tests pass that should not pass and typically causes a link failure
> > later.
> 
> But you want /usr/include to be found.  Otherwise you would not be able
> to use most of the libraries for cross compiling.

This is a two-sided sword. When you want to use libraries, you don't get
around to using /usr/include, but as you use it your configure checks
become unreliable. You check for a header and it happens to exist there,
but the library is installed for a different architecture and you cannot
actually use it. For cross compilation (and for building cross
toolchains), it would actually be better if /usr/include were only
hosting header-only libraries and all other libraries were moved to
/usr/include/<triplet> to avoid such misdetections. This is particularly
the case for the cross toolchain build where such misdetections
historically have been a problem and LIMITS_H_TEST is still broken
today.

> >      . While I do not have a concrete example at hand, I have seen this
> > pattern repeatedly and generally favour moving stuff out of /usr/include
> > to avoid this kind of confusion that causes difficult to debug problems.
> > This also motivates #798955 (in addition to the problem with file
> > conflicts).
> 
> In this case here, this would just find kernel headers for a different
> version.  Those are essentially a headers only library, nothing is
> available for linking.  And all the headers provided in /usr/include are
> the same for all architectures.

As much as I'd like to see kernel headers as architecture-independent,
they really are not. When building a cross toolchain for say hurd, we
really want linux headers to not be found despite requiring
linux-libc-dev to be installed for the build architecture.

> So moving stuff out of /usr/include might be a good idea if the -dev
> package is itself arch dependent.

linux-libc-dev is architecture-dependent. Its annotation of being
Multi-Arch: foreign is a technical lie, that happens make a number of
things easier, but at the same time it breaks the dependency system by
claiming e.g.  linux-libc-dev:hurd-i386 to be a satisfiable dependency
while factually using it that way is broken and doesn't work.  It's not
only that, it also claims to satisfy linux-libc-dev:avr32 and doesn't
provide that functionality either.

That said, having this abstraction break in these corner cases may be a
reasonable compromise due to the benefits it brings in other areas.
Personally, I haven't reached a conclusion regarding this and accept
that you have. I note that libc6 being Multi-Arch: same also is a
technical lie (due to dynamic linker collisions), but a very useful one
in practice. Evidently, following the specification to the letter is not
always the right choice.

> Yep.  My problem is: I tested stuff, not everything of course, and did
> not see any breakage.  Also I checked the values I know could influence
> that and they say it is fine.  So at some point I have to assume it is
> not broken, as exhaustive search is simply not possible.

I locally reproduced the failure to build a cross toolchain and tell you
that something is broken right now. That something is fixable with the
7-line patch to gcc's debian/rules2 I sent yesterday. We don't have to
argue whether there is a known problem. We rightfully argue whether it
needs to be fixed in linux-libc-dev though.

> The only statement in this bug report is now: it is located in a
> different location, so it is broken.  No single piece of evidence is
> shown, like broken builds or some other ways to see the brokeness.

Having thought about this a little more, I may be seeing another angle
of this. In effect, *-dev-*-cross as a package names comes with an
implied contract of installing its things to
/usr/<triplet>/{include,lib,...}. Your providing of these package names
(that I suggested you to do not realizing what that would entail) is
breaking this contract and maybe this is what Matthias is complaining
about. Changing such a contract usually involves declaring Breaks, but
you cannot declare them for a source package and it is not clear that
there is consensus on changing this contract.

Keep in mind, that I suggested providing these provides as a workaround
for the technical lie of Multi-Arch:foreign. We may still rename these
provides.

Maybe we can disarm the whole situation by changing these virtual
facilities as we change the contract? If linux-libc-dev were to drop the
"-cross" suffix (but not the "-$arch" suffix) on its provides, it would
no longer be breaking the implied *-dev-*-cross contract by not
following it s naming scheme. Then, gcc could adopt my patch at its own
pace and switch its dependency at that time.

Also note that we could be fixing the lie of Multi-Arch:foreign in a
technically reasonable way that does not significantly degrade the
benefits achieved. You could rename linux-libc-dev to an implementation
detail package and reintroduce linux-libc-dev as an Arch:any, M-A:same
package that depends on the renamed package. The
/usr/include/<multiarch> symlinks could reasonably be moved to the new
packages while keeping the actual headers in the Arch:all package. That
way, we'd incur another binary package on most systems but not
significantly increase the archive space required, because the M-A:same
packages would be quite small. At that point, the need for having any
Provides would vanish, because it would no longer lie about Multi-Arch.

Helmut