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
Reply to: