cross-toolchain-base-devs team mailing list archive

[Bastian Blank <waldi@xxxxxxxxxx>]

Hi Helmut

On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote:
> > Care to just share what you actually found?  Where is it broken and how
> > to see this?
> > Because this whole thing started with "it is broken, but I won't tell
> > you where or what or how".
> Quite clearly, this is not a single problem, but a mesh of problems and
> in a few cases it is not obvious where to solve them.

Okay, if you re-use a bug report for different things, then problem is
not defined any more.

> > I wonder now.  How would that ever work for the native build?  Or does
> > the native build already do those symlinks?  Or are native and cross
> > configured differently?  Or is that a weird difference in gcc itself?
> Native and cross builds work quite differently indeed.

Both somehow use /usr/include and /usr/include/$multiarch in the end.
So the question remains: why can the native gcc properly use headers
from there to build, but the cross one seems to be unable?

> 1. API expectation of *-$arch-cross packages

I asked exactly that in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#55

> 4. cross-toolchain-base being bd-uninstallable

Which directly correlates to undocumented Build-Conflicts in the
package.  They neither show up in the changelog or the commit logs.

>    I don't exactly understand why it declares them, but I guess that
>    having a different set of kernel headers available in
>    /usr/$DEB_HOST_GNU_TYPE would cause them to be picked up by the build
>    and potentially cause misbuilds. cross-toolchain-base builds these
>    packages and it also uses them during build of glibc.

So this reason is now gone.  linux-source-* and linux-libc-dev are
similar enough in almost all cases.

During the next step it could just loose the special setup for those
headers and just use them from linux-libc-dev.  Then there is not longer
a chance of mixup.

> 5. gcc-V-cross not being buildable
> 
>    The gcc-V-cross package relies on -$arch-cross packages usually built
>    from cross-toolchain-base and expects them to provide their
>    functionality in /usr/$DEB_HOST_GNU_TYPE. The current linux-libc-dev
>    provides the package names but not the expected path (this actually
>    is the first problem) and as a consequence, gcc-V-cross currently
>    fails to build from source.

Finally we get somewhere.

> 6. Cross bootstrap cannot tell whether linux-libc-dev supports an
>    architecture

Even in the past it could not.  It could try to build the linux package
to see if it gets a working linux-libc-dev.  Or have other code to hack
around, like changing the config.

> 7. Cross bootstrap needs to deal with Arch:all packages
> 
>    Until linux-libc-dev became an architecture-dependent Arch:all
>    package, the entire cross bootstrap was possible by only performing
>    arch-only builds and using a repository of only arch:any packages
>    used in conjunction with a Debian mirror restricted to Arch:all
>    packages. Now, the bootstrap repository must also be able to carry
>    an Arch:all package and handle the fact that multiple versions of
>    linux-libc-dev exist in a bootstrap setting one of which does not
>    work (as a result of the second problem).

So now the arch:all package part of the archive already contains a
working linux-libc-dev.  At least if you ask for it first, instead of
patching packages inline.

> 8. Duplication of functionality via -$arch-cross packages
> 
>    When performing cross builds, we currently need both -$arch-cross
>    packages and :$arch packages for glibc and linux-libc-dev. These can
>    be built from different versions and we know that using
>    libc6-dev-$arch-cross packages built from a different glibc version
>    than libc6-dev:$arch together causes problems (repeatedly) and hence
>    glibc now declares Conflicts with old libc6-dev-$arch-cross packages.
>    If gcc-V-cross were to use :$arch packages, it would have to declare
>    cross-architecture dependencies, which is not currently supported by
>    our buildd network. That is one reason for it still using
>    -$arch-cross packages.

Actually linux-libc-dev-$arch-cross is uncommunicated and uncoordinated
duplication of exactly the same content as linux-libc-dev.

9. linux-libc-dev-*-cross provides incompatible headers to
   build-essential

   Both linux-libc-dev and linux-libc-dev-*-cross provide the linux/*
   includes that are used by the compiler but of different versions.  It
   is undefined if those can work with the (always older) asm/* provided
   by linux-libc-dev-*-cross.

   This is fixed by the unification done.

2+3+6+7. linux-libc-dev provides linux-libc-dev-$arch and remains
arch:all.  Then the API for pulling in the correct one will shift.
This also allows to build linux-libc-dev-$arch as special case for
bootstrap purposes without much chance of it showing up in the wrong
location.

The oposite is also working.  linux-libc-dev becomes not-all again, but
is empty and pulls in linux-libc-dev-common, which contains the current
content.  However you no can not longer distinguish if linux-libc-dev is
a bootstrap one with content or empty.

> 3. cross-toolchain-base could build a linux-libc-dev-cross package
>    that Provides the earlier -$arch-cross packages and contains a
>    similar symlink farm to linux-libc-dev.

This requires coordination of the versions and strict enough
dependencies.  So linux-libc-dev-cross would need to come out of the
same source as linux-libc-dev.

> 4. cross-toolchain-base could drop its Build-Conflicts. This may cause
>    further problems though.
>    Patch: https://bugs.debian.org/1067370#17

The build will now see multiple architectures of headers.  So it needs
to handle this both for native (where build-conflicts can't be used
anyway) and cross the same.

> 5. gcc-V-cross could create its own symlink farm for linux-libc-dev at
>    build time and pass that to the gcc build removing the need for the
>    /usr/$DEB_HOST_GNU_TYPE location.
>    Patch: https://bugs.debian.org/1065416#129

The native build is already able to do that?  So it would be reduction
of differences between both worlds?

8. cross-toolchain-base looses it's own setup for headers provided by
Linux.

Bastian

-- 
Well, Jim, I'm not much of an actor either.