Re: Arch triplet for uefi applications
On Fri, 13 Aug 2021 at 02:29:02 +0200, Guillem Jover wrote:
> On Tue, 2021-08-10 at 12:34:18 +0000, Bastien Roucariès wrote:
> > I am going to compile shell.efi from source.
> >
> > I whish to install to something stable, but I need an arch triplet
> > in order to put in a multiarch (like) location.
>
> Multiarch-based pathnames should only be used by multiarch-conforming
> packages for matching and existing dpkg architectures, otherwise we'll
> end up with a mess of conflicting paths if we ever add such real
> architecture.
Yes. Policy specifically forbids multiarch paths for cross-architecture
packages, for the reasons Guillem mentioned:
Packages may *not* install files to any triplet path other than the
one matching the architecture of that package; for instance, an
Architecture: amd64 package containing 32-bit x86 libraries may
not install these libraries to /usr/lib/i386-linux-gnu
I think this remains equally necessary when the triplet path is one that
does not (yet?) correspond to a dpkg architecture.
For existing precedent for this, look at mingw (Windows binaries compiled
by a gcc-based toolchain). These use the traditional cross-compiling
layout involving /usr/${gnu_tuple}, for example:
- binutils-mingw-w64-i686 contains e.g.
/usr/bin/i686-w64-mingw32-ld, also known as
/usr/i686-w64-mingw32/bin/ld
- libz-mingw-w64 is Architecture: all and contains:
+ /usr/i686-w64-mingw32/lib/zlib1.dll
+ /usr/x86_64-w64-mingw32/lib/zlib1.dll
If we were using multiarch, then libz-mingw-w64 would be replaced by
something more like this:
- zlib1:mingw-i386 is Architecture: mingw-i386 and contains
/usr/lib/i386-mingw32/zlib1.dll
- zlib1:mingw-amd64 is Architecture: mingw-amd64 and contains
/usr/lib/x86_64-mingw32/zlib1.dll
But we are not using multiarch for this, partly because "partial
architectures" or "freestanding architectures" don't exist in the archive
yet, and partly because if I understand correctly, i686-w64-mingw32 is
not suitable to be a dpkg architecture because the -w64- vendor part of
its tuple is significant to the ABI.
Similarly, it would only be correct to install /usr/lib/x86_64-uefi/libfoo.a
if it was in a libfoo-dev:uefi-amd64 package, for a uefi-amd64 architecture
that does not exist yet. If it's in an Architecture: amd64 or
Architecture: all package, then you would need to install into the
traditional cross-compilation location, /usr/x86_64-uefi/libfoo.a.
> In addition the main reason we had to add the multiarch tuples was
> pretty much to workaround the problem with i386 using varying CPUs in
> the GNU system name (i486, i586, i686), so using anything but i386
> there would be adding insult to injury. :)
As far as i386 vs. i686 goes, the damage has already been done (by
i?86-linux-gnu, i?86-freebsd, etc.), so using i686-unknown-uefi as the
GNU tuple (as Rust already does) is no worse than every other 32-bit
x86 architecture.
However, I agree that if we had a multiarch tuple for 32-bit UEFI,
then *that* would be i386-uefi (normalizing i?86 to i386 and dropping
the vendor as usual).
smcv
Reply to: