Bug#1064003: 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
Hi On Sun, May 12, 2024 at 11:54:42PM +0200, Helmut Grohne wrote: > On Sun, May 12, 2024 at 07:35:09PM +0200, Bastian Blank wrote: > > > 1. API expectation of *-$arch-cross packages > > I asked exactly that in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#55 > I guess the best description is to be found in man dpkg-cross > "Conversion process" and even that isn't entirely helpful. This is now https://salsa.debian.org/kernel-team/linux/-/merge_requests/1076 Not really tested however. Until cross-toolchain-base is rebuilt, we don't have any test subject. > > > 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. > > I don't understand what you are trying to say here. c-t-b only builds > Arch:all packages, so the terms native and cross appear to not apply. > Then again we also don't know what "further problems" are. I hope > Matthias can shed some light here. gcc-13, the native compiler, builds fine with headers in /usr/include and /usr/include/$multiarch. gcc-13-cross, the cross compiler, is reported to not build with this, however I can't verify that right now. > > On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote: > > > 2+3+6+7. linux-libc-dev could be split into linux-libc-dev-common > > >arch:all m-a:foreign and the symlink farms could be kept in > > >linux-libc-dev:any m-a:same retaining the size reduction. > > > > This would not actually work. linux-libc-dev-common would only contain > > known architectures. So the current "change config, build > > linux-libc-dev" will not longer work as well. This package would then > > depend on a linux-libc-dev-common without the headers for this > > architecture. > > I agree that it is not as simple as I pictured it. I was imagining that > a m-a:same linux-libc-dev could simply contain all the > architecture-dependent stuff. For many architectures that would > practically work initially, but there is no bijective mapping between > kernel architecture names and Debian architecture names, so for > directories like /usr/lib/linux/uapi/arm is is unclear whether it should > be part of linux-libc-dev:armel or linux-libc-dev:armhf or > linux-libc-dev-common. Even for /usr/lib/linux/uapi/arm64, it is not > clear whether that should be part of linux-libc-dev:arm64 or > linux-libc-dev:musl-linux-arm64 or linux-libc-dev-common. You are > implicitly resolving this to linux-libc-dev-common and conclude that > headers would then go missing. > > Given this, I fear I concur with your "This would not actually work." linux-libc-dev is also build-essential. This kind of rules out any same-source all-any trickery. Those packages will not show up at the same time, so are prone to make the whole toolchain uninstallable. Bastian -- Vulcans believe peace should not depend on force. -- Amanda, "Journey to Babel", stardate 3842.3
Bug#1064003: 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
Hi Bastian, I've intentionally snipped much of your reply as I think we two agree on many of the aspects. On Sun, May 12, 2024 at 07:35:09PM +0200, Bastian Blank wrote: > > 1. API expectation of *-$arch-cross packages > > I asked exactly that in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#55 I guess the best description is to be found in man dpkg-cross "Conversion process" and even that isn't entirely helpful. > > 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. It's not gone as non-virtual linux-libc-dev-$arch-cross packages are still built from c-t-b. If c-t-b were to stop building them, I'd concur. > > 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. In the past, there was no need to tell. It would always build linux-libc-dev. Now that linux-libc-dev works for many but not all architectures, there is a need to tell. > Actually linux-libc-dev-$arch-cross is uncommunicated and uncoordinated > duplication of exactly the same content as linux-libc-dev. It is news to me that it is uncommunicated and uncoordinated, but that very accurately matches the rest of the disagreement. Yes, it is duplication. > 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. Yes, this is a problem. It kinda is the same problem that we have with libc6-dev vs libc6-dev-$arch-cross and is why libc6-dev declares versioned breaks for libc6-dev-$arch-cross. > > 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. Technically speaking, a linux-libc-dev-cross package could be built from c-t-b. It would just inherit all the other problems including your problem 9 from the previous approach and only address the space aspect. I listed it more for completeness sake than suggesting we actually go for this. > > 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. I don't understand what you are trying to say here. c-t-b only builds Arch:all packages, so the terms native and cross appear to not apply. Then again we also don't know what "further problems" are. I hope Matthias can shed some light here. > On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote: > > 2+3+6+7. linux-libc-dev could be split into linux-libc-dev-common > >arch:all m-a:foreign and the symlink farms could be kept in > >linux-libc-dev:any m-a:same retaining the size reduction. > > This would not actually work. linux-libc-dev-common would only contain > known architectures. So the current "change config, build > linux-libc-dev" will not longer work as well. This package would then > depend on a linux-libc-dev-common without the headers for this > architecture. I agree that it is not as simple as I pictured it. I was imagining that a m-a:same linux-libc-dev could simply contain all the architecture-dependent stuff. For many architectures that would practically work initially, but there is no bijective mapping between kernel architecture names and Debian architecture names, so for directories like /usr/lib/linux/uapi/arm is is unclear whether it should be part of linux-libc-dev:armel or linux-libc-dev:armhf or linux-libc-dev-common. Even for /usr/lib/linux/uapi/arm64, it is not clear whether that should be part of linux-libc-dev:arm64 or linux-libc-dev:musl-linux-arm64 or linux-libc-dev-common. You are implicitly resolving this to linux-libc-dev-common and conclude that
Bug#1064003: 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
On Sun, May 12, 2024 at 01:53:33PM +0200, Helmut Grohne wrote: > 2+3+6+7. linux-libc-dev could be split into linux-libc-dev-common >arch:all m-a:foreign and the symlink farms could be kept in >linux-libc-dev:any m-a:same retaining the size reduction. This would not actually work. linux-libc-dev-common would only contain known architectures. So the current "change config, build linux-libc-dev" will not longer work as well. This package would then depend on a linux-libc-dev-common without the headers for this architecture. Bastian -- To live is always desirable. -- Eleen the Capellan, "Friday's Child", stardate 3498.9
Bug#1064003: 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
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
Bug#1064003: 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
Hi, In this mail, I'll try to summarize my state of knowledge on this matter while noting that I don't see the full picture. On Fri, Mar 29, 2024 at 11:17:55AM +0100, Bastian Blank wrote: > On Thu, Mar 21, 2024 at 08:48:01PM +0100, Helmut Grohne wrote: > > I was recently working on gcc builds and this disagreement currently > > makes stuff unbuildable. Hence I looked into solutions and/or > > workarounds. > > 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. > > As a result, I implemented the proposed change and am attaching it for > > discussion here. I've implemented it in a way that if there is a sysroot > > linux header installation, it'll be preferred. Do you see any downsides > > of this approach? > > 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. So let me first try to collect all relevant problems that I encountered here. I vaguely try to list the more important ones earlier. I have caused some of these problems and don't want to assign any blame but look for solutions. 1. API expectation of *-$arch-cross packages When *-$arch-cross packages were first introduced before multiarch was a thing, there was (and still is) and implicit contract saying that their functionality is to be provided within the /usr/$DEB_HOST_GNU_TYPE hierarchy. In particular, this layout does not interfere with multiarch on a filesystem level and hence *-$arch-cross packages typically are arch:all m-a:foreign. In particular, linux-libc-dev now provides such packages without actually providing those paths violating this implicit contract. 2. Violation of Multi-Arch: foreign linux-libc-dev was changed from an Arch:any + Multi-Arch:same package to an Architecture:all + Multi-Arch:foreign package. It does so by providing the headers for all architectures in a single package via symlink farms. "all" architectures is debatable though. The set of architectures changes rather frequently with new ones being added and old ones being removed. Therefore, linux-libc-dev will often look like it provides linux-libc-dev:$somearch to dependency resolvers while in fact not providing the functionality - thus violating the promise of Multi-Arch: foreign. For example, linux-libc-dev is currently dysfunctional for arc, but next year it'll be a different architecture. Moreover, looking at the metadata of linux-libc-dev initially did not provide means of figuring out which architectures were actually supported and which were not. This has been changed as linux-libc-dev now Provides linux-libc-dev-$arch-cross packages (causing the first problem), but at least giving bootstrappers a means to figure out whether a given linux-libc-dev package is usable to them. 3. linux-libc-dev consumes much space on mirrors and installations linux-libc-dev originally was Arch:any and yet much of its content was the same across architectures albeit in different paths. Thus, the size of the .deb (multiplied by the number of architectures) was quite big and also coinstalling linux-libc-dev would result in duplicate files being extracted to multiple locations increasing the installation size in a multiarch setting. As a result, linux-libc-dev now is Arch:all and we only get to have one package. It grew from about 1.8MB (times 10 architectures) to about 2.2MB and its installed size grew from about 7MB (per architecture) to 10MB (for all architectures). This change caused the second problem. 4. cross-toolchain-base being bd-uninstallable cross-toolchain-base cannot currently be built (FTBFS #1064003 and #1067370) and one of the aspects is that it declares Build-Conflicts with linux-libc-dev-$arch-cross. The recently added Provides on linux-libc-dev satisfy them and thus cause cross-toolchain-base to be bd-uninstallable. 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. 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
Bug#1064003: 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
Hi On Thu, Mar 21, 2024 at 08:48:01PM +0100, Helmut Grohne wrote: > I was recently working on gcc builds and this disagreement currently > makes stuff unbuildable. Hence I looked into solutions and/or > workarounds. 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". > On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote: > > > You just said that the search path used during the build of the > > > toolchain and the one for everything else are unrelated. So you are > > > free to create $BUILD/tmp-include with symlinks for asm, asm-generic, > > > linux. > > > > > > The toolchain as installed already finds all headers. So I still don't > > > see why we need this in the final system. > > > > I find this argument fairly convincing and hope Matthias also does. > > As a result, I implemented the proposed change and am attaching it for > discussion here. I've implemented it in a way that if there is a sysroot > linux header installation, it'll be preferred. Do you see any downsides > of this approach? 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? Bastian -- Oblivion together does not frighten me, beloved. -- Thalassa (in Anne Mulhall's body), "Return to Tomorrow", stardate 4770.3.
Bug#1064003: 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
Hi Bastian and Matthias, I was recently working on gcc builds and this disagreement currently makes stuff unbuildable. Hence I looked into solutions and/or workarounds. On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote: > > You just said that the search path used during the build of the > > toolchain and the one for everything else are unrelated. So you are > > free to create $BUILD/tmp-include with symlinks for asm, asm-generic, > > linux. > > > > The toolchain as installed already finds all headers. So I still don't > > see why we need this in the final system. > > I find this argument fairly convincing and hope Matthias also does. As a result, I implemented the proposed change and am attaching it for discussion here. I've implemented it in a way that if there is a sysroot linux header installation, it'll be preferred. Do you see any downsides of this approach? Helmut linux-libc-dev now provides linux-libc-dev-$arch-cross without actually providing /usr//include. Thus we symlink it to where we need it. See also #1064003. diff --git a/debian/rules2 b/debian/rules2 index 651d14af..6a486ffe 100644 --- a/debian/rules2 +++ b/debian/rules2 @@ -1266,6 +1266,13 @@ endif ln -sf /usr/include/$(DEB_HOST_MULTIARCH)/crypt.h \ $(builddir)/sys-include/crypt.h; \ fi + : # Import headers from Multi-Arch:foreign linux-libc-dev + set -e; for d in asm-generic linux; do \ + if [ -d "/usr/include/$$d" ] && ! [ -d "/usr/$(DEB_TARGET_GNU_TYPE)/include/$$d" ]; then \ + mkdir -p '$(builddir)/sys-include'; \ + ln -sf "/usr/include/$$d" "$(builddir)/sys-include/$$d"; \ + fi; \ + done touch $(configure_stamp)
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
Hi Helmut 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. > . 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. So moving stuff out of /usr/include might be a good idea if the -dev package is itself arch dependent. > The one case I really do remember quite well is sanitizers. These should > not be enabled in the earlier toolchain stages and failing to disable > them tends to cause linker failures. I don't think it matches the > concrete situation exactly though. You also make a good case in your > followup reporting that gcc-13-cross actually builds. 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. 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. Regards, Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3
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
Hi Bastian, On Mon, Mar 04, 2024 at 11:04:22PM +0100, Bastian Blank wrote: > > Arguably, a cross toolchain build should probably search > > /usr/include/. I went back and forth a bit with Matthias > > about whether we could add this and did not fully understand his > > reasons, but there is one technical reason we want to avoid it for now. > > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed > > and these packages can have differing versions. When that happens and we > > search both /usr//include and /usr/include/, we'd > > mix two glibc versions with usually bad results (been there). > > But this is a search path. If a file exists in one, the second one is > not found. So nothing can happen even from version skew. 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. 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). > > The other aspect here is that it is not sufficient to add > > /usr/include/ to the search path as you also need > > /usr/include to get a complete linux kernel headers experience. We > > definitely do not want to add /usr/include, because that is known to > > misguide configure tests performed for the target architecture. > > We are talking about the toolchain itself. What configure tests could > that be? Or is that premature optimization of the gcc build? The one case I really do remember quite well is sanitizers. These should not be enabled in the earlier toolchain stages and failing to disable them tends to cause linker failures. I don't think it matches the concrete situation exactly though. You also make a good case in your followup reporting that gcc-13-cross actually builds. > You just said that the search path used during the build of the > toolchain and the one for everything else are unrelated. So you are > free to create $BUILD/tmp-include with symlinks for asm, asm-generic, > linux. > > The toolchain as installed already finds all headers. So I still don't > see why we need this in the final system. I find this argument fairly convincing and hope Matthias also does. Thank you Helmut
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
On Mon, Mar 04, 2024 at 11:04:23PM +0100, Bastian Blank wrote: > At least to show where it breaks. And I actually tried it and can not show the expected breakage from missing /usr/include in the search path. gcc-13-cross builds fine with only linux-libc-dev/6.7.7-1. | -rw-r--r-- 1 bastian bastian 38157 Mar 5 06:40 ../gcc-13-cross_14_amd64.changes Bastian -- You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown
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
On Mon, Mar 04, 2024 at 01:49:24PM +0100, Helmut Grohne wrote: > The packaged gcc cross toolchain uses a sysroot during its own build > still. As it is implemented now, it searches /usr//include, but > not /usr/include/. So quite fundamentally, the Provides that > we two agreed do break the build of cross toolchains right now. Okay, so this problem is about the build of the toolchain, _not_ for everything that comes after. > Arguably, a cross toolchain build should probably search > /usr/include/. I went back and forth a bit with Matthias > about whether we could add this and did not fully understand his > reasons, but there is one technical reason we want to avoid it for now. > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed > and these packages can have differing versions. When that happens and we > search both /usr//include and /usr/include/, we'd > mix two glibc versions with usually bad results (been there). But this is a search path. If a file exists in one, the second one is not found. So nothing can happen even from version skew. > The other aspect here is that it is not sufficient to add > /usr/include/ to the search path as you also need > /usr/include to get a complete linux kernel headers experience. We > definitely do not want to add /usr/include, because that is known to > misguide configure tests performed for the target architecture. We are talking about the toolchain itself. What configure tests could that be? Or is that premature optimization of the gcc build? > So at least for now, I am convinced that we will need > /usr//include to be provided by the package providing > linux-libc-dev-arch-cross. You just said that the search path used during the build of the toolchain and the one for everything else are unrelated. So you are free to create $BUILD/tmp-include with symlinks for asm, asm-generic, linux. The toolchain as installed already finds all headers. So I still don't see why we need this in the final system. > That still leaves the question of which package would have to build that > new linux-libc-dev-cross. The two obvious answers are linux and > cross-toolchain-base. Do you have a preference here? No, the gcc build itself, because it is the only part that needs it from what you said here. > I hope this all makes more sense now. At least to show where it breaks. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
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
Hi Bastian, On Mon, Mar 04, 2024 at 12:30:09PM +0100, Bastian Blank wrote: > On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote: > > On 04.03.24 11:29, Bastian Blank wrote: > > > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > > > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. > > > > > > Please be a bit more precise, there are no symlinks in this directory. > > > | # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h > > > | linux-libc-dev-alpha-cross: /usr/alpha-linux-gnu/include/asm/a.out.h > > > | # find /usr/alpha-linux-gnu/include/ -type l > > > | # > > yes, that is the problem. the cross gcc expects these headers in > > /usr/alpha-linux-gnu/include, not in the header location for the host. > > Please show your problem with a log, my crystal ball is broken. This very much was not obvious to me either. I've now talked to Matthias and believe I can explain the problem. The packaged gcc cross toolchain uses a sysroot during its own build still. As it is implemented now, it searches /usr//include, but not /usr/include/. So quite fundamentally, the Provides that we two agreed do break the build of cross toolchains right now. Arguably, a cross toolchain build should probably search /usr/include/. I went back and forth a bit with Matthias about whether we could add this and did not fully understand his reasons, but there is one technical reason we want to avoid it for now. We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed and these packages can have differing versions. When that happens and we search both /usr//include and /usr/include/, we'd mix two glibc versions with usually bad results (been there). While we might consider adding /usr/include/ to the cross toolchain build search path later, it is not something we can do now and before doing that, we need to better understand Matthias' reasons for keeping these separate as well. The other aspect here is that it is not sufficient to add /usr/include/ to the search path as you also need /usr/include to get a complete linux kernel headers experience. We definitely do not want to add /usr/include, because that is known to misguide configure tests performed for the target architecture. In principle, we could extend the symlink farm in linux-libc-dev to also have a lot of /usr/include//linux -> ../linux symlinks (assuming that no other package ever installs to /usr/include/linux, which is a property violated by aufs-dev and oss4-dev). So at least for now, I am convinced that we will need /usr//include to be provided by the package providing linux-libc-dev-arch-cross. As these are only necessary for building the cross toolchains, we probably don't want these in the main linux-libc-dev package. So how about adding a linux-libc-dev-cross package with yet more symlinks? Then we can move the provides over to the linux-libc-dev-cross package and that way repair the cross toolchain builds. I requested that linux-libc-dev provides these for bootstrapping to know which architectures linux-libc-dev actually supports. I don't need these provides exactly, I just need a mechanism to answer the question "Does linux-libc-dev work for a particular architecture?" from the binary package metadata, so we might just change the Provides there to linux-libc-dev-arch dropping the -cross suffix that traditionally identified packages putting stuff into /usr/. Does that sound reasonable to you? That still leaves the question of which package would have to build that new linux-libc-dev-cross. The two obvious answers are linux and cross-toolchain-base. Do you have a preference here? I hope this all makes more sense now. Helmut
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
On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote: > On 04.03.24 11:29, Bastian Blank wrote: > > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. > > > > Please be a bit more precise, there are no symlinks in this directory. > > | # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h > > | linux-libc-dev-alpha-cross: /usr/alpha-linux-gnu/include/asm/a.out.h > > | # find /usr/alpha-linux-gnu/include/ -type l > > | # > yes, that is the problem. the cross gcc expects these headers in > /usr/alpha-linux-gnu/include, not in the header location for the host. Please show your problem with a log, my crystal ball is broken. arm-linux-gnueabihf-cpp-13 tells me: | #include <...> search starts here: | /usr/lib/gcc-cross/arm-linux-gnueabihf/13/include | /usr/lib/gcc-cross/arm-linux-gnueabihf/13/../../../../arm-linux-gnueabihf/include | /usr/include/arm-linux-gnueabihf | /usr/include | End of search list. So clearly /usr/include/arm-linux-gnueabihf is used. Regards, Bastian -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3
