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.
