cross-toolchain-base-devs team mailing list archive

[Bastian Blank <waldi@xxxxxxxxxx>]

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