Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #100943 > unrolled thread

Arch triplet for uefi applications

Back to article view | Back to linux.debian.devel

Contents

  Arch triplet for uefi applications "Bastien Roucariès" <roucaries.bastien@gmail.com> - 2021-08-10 14:40 +0200
    Re: Arch triplet for uefi applications Josh Triplett <josh@joshtriplett.org> - 2021-08-11 00:20 +0200
      Re: Arch triplet for uefi applications Simon McVittie <smcv@debian.org> - 2021-08-11 11:20 +0200
        Re: Arch triplet for uefi applications "Bastien Roucariès" <roucaries.bastien@gmail.com> - 2021-08-13 14:40 +0200
      Re: Arch triplet for uefi applications Steve McIntyre <steve@einval.com> - 2021-08-11 16:10 +0200
        Re: Arch triplet for uefi applications "Bastien Roucariès" <roucaries.bastien@gmail.com> - 2021-08-12 12:00 +0200
          Re: Arch triplet for uefi applications "Bastien Roucariès" <roucaries.bastien@gmail.com> - 2021-08-12 12:20 +0200
            Re: Arch triplet for uefi applications "Bastien Roucariès" <roucaries.bastien@gmail.com> - 2021-08-12 14:10 +0200
    Re: Arch triplet for uefi applications Guillem Jover <guillem@debian.org> - 2021-08-13 02:30 +0200
      Re: Arch triplet for uefi applications Simon McVittie <smcv@debian.org> - 2021-08-13 11:00 +0200
      Re: Arch triplet for uefi applications "Bastien Roucariès" <roucaries.bastien@gmail.com> - 2021-08-13 11:20 +0200

#100943 — Arch triplet for uefi applications

[Multipart message — attachments visible in raw view] — view raw

Hi,

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.

I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi  )  and 
i686-uefi-none ? Note that grub use x86_64-efi

I suppose we should register these triplet somewhere, and I suppose it is 
config-patches@gnu.org ?

Bastien

[toc] | [next] | [standalone]

#100947

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.
> 
> I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi  )  and 
> i686-uefi-none ?

I don't think GRUB's x86_64-efi is an architecture triplet, just a
GRUB-specific target.

UEFI is effectively an "operating system", insofar as it provides a
runtime environment with some baseline properties and a set of system
calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
since there is an OS of sorts.

For that reason, Rust uses the target names "aarch64-unknown-uefi",
"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
right names for these targets in other toolchains, as well.

- Josh Triplett

[toc] | [prev] | [next] | [standalone]

#100951

On Tue, 10 Aug 2021 at 15:19:10 -0700, Josh Triplett wrote:
> Bastien Roucariès wrote:
> > I suppose that [EFI] will be  x86_64-efi-none (or maybe x86_64-windows-efi  )  and 
> > i686-uefi-none ?

It's certainly not x86_64-windows-efi. The EFI environment isn't Windows
(even though it borrows some conventions like FAT, backslashes in paths
and the PE executable format from Windows).

> UEFI is effectively an "operating system", insofar as it provides a
> runtime environment with some baseline properties and a set of system
> calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> since there is an OS of sorts.
> 
> For that reason, Rust uses the target names "aarch64-unknown-uefi",
> "i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> right names for these targets in other toolchains, as well.

These names used in Rust seem correct to me. The UEFI environment behaves
like a miniature operating system, which runs instead of GNU/Linux during
the first stage of boot, so replacing the linux-gnu part of the tuple with
uefi makes sense.

Note that there are two forms for writing a GNU tuple: with or without
the vendor. The full tuple consists of CPU-VENDOR-OS, where OS sometimes
consists of KERNEL-USERSPACE, or KERNEL-ABI, or KERNEL-USERSPACEABI where
both disambiguators are needed.

Developers who are used to (GNU/)Linux are likely to think the
KERNEL-USERSPACE form is most common, but actually that one is the
exception, and the more usual form has traditionally just had a single
token for OSs where the kernel and user-space are tightly coupled,
such as solaris2, netbsd or freebsd:

                                 |CPU    |vendor |kernel |userspace|ABI
                                 |       |       |       | (libc)  |
    -----------------------------|-------|-------|-------|---------|----
    i386-pc-solaris2             |i386   |PC     |    Solaris 2    |
    x86_64-pc-freebsd            |x86_64 |PC     |    FreeBSD      |
    arm-unknown-netbsd-eabi      |arm    |unknown|    NetBSD       |EABI
    x86_64-unknown-uefi          |x86_64 |unknown|     UEFI        |
    x86_64-pc-linux-gnu          |x86_64 |PC     |Linux  |GNU      |
    x86_64-pc-linux-musl         |x86_64 |PC     |Linux  |musl libc|
    x86_64-pc-linux-gnux32       |x86_64 |PC     |Linux  |GNU      |x32
    aarch64-unknown-linux-gnu    |aarch64|unknown|Linux  |GNU      |
    arm-unknown-linux-gnu        |arm    |unknown|Linux  |GNU      |OABI
    arm-unknown-linux-gnueabi    |arm    |unknown|Linux  |GNU      |EABI
    x86_64-pc-kfreebsd-gnu       |x86_64 |PC     |FreeBSD|GNU      |

In Debian multiarch tuples and GNU-style cross-compilation tool
prefixes, the tuple is written in a shorter form without the vendor as
CPU-OS (where, again, the OS might be KERNEL-USERSPACE or KERNEL-ABI or
KERNEL-USERSPACEABI), because the vendor is not usually significant when
determining whether two binaries share an ABI and can interoperate:

    i386-solaris2
    x86_64-freebsd
    arm-netbsd-eabi
    x86_64-uefi
    x86_64-linux-gnu
    x86_64-linux-musl
    x86_64-linux-gnux32
    aarch64-linux-gnu
    arm-linux-gnu
    arm-linux-gnueabi
    x86_64-kfreebsd-gnu

(For instance we have x86_64-linux-gnu-gcc and /usr/lib/x86_64-linux-gnu.)

I prefer to call these strings tuples rather than triplets, because
calling them triplets can be misleading. The "target triplet" in Autoconf
specifically refers to the CPU-VENDOR-OS arrangment - remember that GNU
started by building Free Software tools to run on top of other (often
proprietary) operating systems, where the ABI was externally imposed by
the OS vendor, so initially it wouldn't have made sense to talk about the
kernel and user-space separately. The Linux, kFreeBSD and Hurd kernels
and the possibility of running a complete GNU operating system only came
later. So "triplet" refers to the three parts of a full tuple with the
vendor, broken up like this:

    <--1-->    <--2-->  <--3-->
    i386-      pc-      solaris2
    x86_64-    pc-      linux-gnu

"Triplet" does not refer to the three parts of an abbreviated
GNU/Linux-style tuple written without the vendor, even though this decade
that's the one we see most often:

    # NOT THIS
    x86_64-    linux-   gnu

because not all operating systems' short-form tuples break down into
three parts like that (as you can see from the Solaris, FreeBSD, NetBSD
examples above).

Traditional cross-compilation (cross-libraries in subdirectories of /usr,
such as /usr/i386-solaris2 or /usr/arm-unknown-netbsd-eabi) might write the
tuple with or without the vendor. In Debian, we use the tuple without the
vendor included for multilib (e.g. /usr/i686-linux-gnu in libc6-i386-cross),
but we use the tuple *with* the vendor included for mingw-w64
(/usr/i686-w64-mingw32, /usr/x86_64-w64-mingw32).

    smcv

[toc] | [prev] | [next] | [standalone]

#101014

[Multipart message — attachments visible in raw view] — view raw

Le mercredi 11 août 2021, 09:16:10 UTC Simon McVittie a écrit :
> On Tue, 10 Aug 2021 at 15:19:10 -0700, Josh Triplett wrote:
> > Bastien Roucariès wrote:
> > > I suppose that [EFI] will be  x86_64-efi-none (or maybe
> > > x86_64-windows-efi  )  and i686-uefi-none ?
> 
> It's certainly not x86_64-windows-efi. The EFI environment isn't Windows
> (even though it borrows some conventions like FAT, backslashes in paths
> and the PE executable format from Windows).
> 
> > UEFI is effectively an "operating system", insofar as it provides a
> > runtime environment with some baseline properties and a set of system
> > calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> > since there is an OS of sorts.
> > 
> > For that reason, Rust uses the target names "aarch64-unknown-uefi",
> > "i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> > right names for these targets in other toolchains, as well.
> 
> These names used in Rust seem correct to me. The UEFI environment behaves
> like a miniature operating system, which runs instead of GNU/Linux during
> the first stage of boot, so replacing the linux-gnu part of the tuple with
> uefi makes sense.
> 
> Note that there are two forms for writing a GNU tuple: with or without
> the vendor. The full tuple consists of CPU-VENDOR-OS, where OS sometimes
> consists of KERNEL-USERSPACE, or KERNEL-ABI, or KERNEL-USERSPACEABI where
> both disambiguators are needed.
> 
> Developers who are used to (GNU/)Linux are likely to think the
> KERNEL-USERSPACE form is most common, but actually that one is the
> exception, and the more usual form has traditionally just had a single
> token for OSs where the kernel and user-space are tightly coupled,
> 
> such as solaris2, netbsd or freebsd:
>                                  |CPU    |vendor |kernel |userspace|ABI
>                                  |
>                                  |       |       |       | (libc)  |
> 
>     -----------------------------|-------|-------|-------|---------|----
>     i386-pc-solaris2             |i386   |PC     |    Solaris 2    |
>     x86_64-pc-freebsd            |x86_64 |PC     |    FreeBSD      |
>     arm-unknown-netbsd-eabi      |arm    |unknown|    NetBSD       |EABI
>     x86_64-unknown-uefi          |x86_64 |unknown|     UEFI        |
>     x86_64-pc-linux-gnu          |x86_64 |PC     |Linux  |GNU      |
>     x86_64-pc-linux-musl         |x86_64 |PC     |Linux  |musl libc|
>     x86_64-pc-linux-gnux32       |x86_64 |PC     |Linux  |GNU      |x32
>     aarch64-unknown-linux-gnu    |aarch64|unknown|Linux  |GNU      |
>     arm-unknown-linux-gnu        |arm    |unknown|Linux  |GNU      |OABI
>     arm-unknown-linux-gnueabi    |arm    |unknown|Linux  |GNU      |EABI
>     x86_64-pc-kfreebsd-gnu       |x86_64 |PC     |FreeBSD|GNU      |
> 
> In Debian multiarch tuples and GNU-style cross-compilation tool
> prefixes, the tuple is written in a shorter form without the vendor as
> CPU-OS (where, again, the OS might be KERNEL-USERSPACE or KERNEL-ABI or
> KERNEL-USERSPACEABI), because the vendor is not usually significant when
> determining whether two binaries share an ABI and can interoperate:
> 
>     i386-solaris2
>     x86_64-freebsd
>     arm-netbsd-eabi
>     x86_64-uefi
>     x86_64-linux-gnu
>     x86_64-linux-musl
>     x86_64-linux-gnux32
>     aarch64-linux-gnu
>     arm-linux-gnu
>     arm-linux-gnueabi
>     x86_64-kfreebsd-gnu
> 
> (For instance we have x86_64-linux-gnu-gcc and /usr/lib/x86_64-linux-gnu.)
> 
> I prefer to call these strings tuples rather than triplets, because
> calling them triplets can be misleading. The "target triplet" in Autoconf
> specifically refers to the CPU-VENDOR-OS arrangment - remember that GNU
> started by building Free Software tools to run on top of other (often
> proprietary) operating systems, where the ABI was externally imposed by
> the OS vendor, so initially it wouldn't have made sense to talk about the
> kernel and user-space separately. The Linux, kFreeBSD and Hurd kernels
> and the possibility of running a complete GNU operating system only came
> later. So "triplet" refers to the three parts of a full tuple with the
> vendor, broken up like this:
> 
>     <--1-->    <--2-->  <--3-->
>     i386-      pc-      solaris2
>     x86_64-    pc-      linux-gnu
> 
> "Triplet" does not refer to the three parts of an abbreviated
> GNU/Linux-style tuple written without the vendor, even though this decade
> that's the one we see most often:
> 
>     # NOT THIS
>     x86_64-    linux-   gnu
> 
> because not all operating systems' short-form tuples break down into
> three parts like that (as you can see from the Solaris, FreeBSD, NetBSD
> examples above).
> 
> Traditional cross-compilation (cross-libraries in subdirectories of /usr,
> such as /usr/i386-solaris2 or /usr/arm-unknown-netbsd-eabi) might write the
> tuple with or without the vendor. In Debian, we use the tuple without the
> vendor included for multilib (e.g. /usr/i686-linux-gnu in libc6-i386-cross),
> but we use the tuple *with* the vendor included for mingw-w64
> (/usr/i686-w64-mingw32, /usr/x86_64-w64-mingw32).

Could be possible to add a sumup tupple vs triplet to the wiki, or push 
something to debian policy

It is hard to understand the relationship between the two, and the wiki is 
terse.

Bastien
> 
>     smcv

[toc] | [prev] | [next] | [standalone]

#100958

On Tue, Aug 10, 2021 at 03:19:10PM -0700, Josh Triplett wrote:
>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.
>> 
>> I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi  )  and 
>> i686-uefi-none ?

As Simon says, *definitely* not *windows* here please! :-)

>I don't think GRUB's x86_64-efi is an architecture triplet, just a
>GRUB-specific target.
>
>UEFI is effectively an "operating system", insofar as it provides a
>runtime environment with some baseline properties and a set of system
>calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
>since there is an OS of sorts.
>
>For that reason, Rust uses the target names "aarch64-unknown-uefi",
>"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
>right names for these targets in other toolchains, as well.

Nod, agreed. I think that makes sense.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
          note stuck to the mini-bar saying "Paul: This fridge and
          fittings are the correct way around and do not need altering"

[toc] | [prev] | [next] | [standalone]

#100985

[Multipart message — attachments visible in raw view] — view raw

Le mercredi 11 août 2021, 14:00:37 UTC Steve McIntyre a écrit :
> On Tue, Aug 10, 2021 at 03:19:10PM -0700, Josh Triplett wrote:
> >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.
> >> 
> >> I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi 
> >> )  and i686-uefi-none ?
> 
> As Simon says, *definitely* not *windows* here please! :-)
> 
> >I don't think GRUB's x86_64-efi is an architecture triplet, just a
> >GRUB-specific target.
> >
> >UEFI is effectively an "operating system", insofar as it provides a
> >runtime environment with some baseline properties and a set of system
> >calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> >since there is an OS of sorts.
> >
> >For that reason, Rust uses the target names "aarch64-unknown-uefi",
> >"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> >right names for these targets in other toolchains, as well.
> 
> Nod, agreed. I think that makes sense.
Ok thanks

For the triplet this will be :
-  i686-unknown-uefi
- x86_64-unknown-uefi
Where should I push this triplet ?

Ant therefore we get the multiarch tupple:
- i386-uefi
- amd64-uefi
If I am right ?
I have added to https://wiki.debian.org/Multiarch/Tuples but I suppuse I 
should open a bug somewhere (dpkg ?)

Bastien

Bastien

[toc] | [prev] | [next] | [standalone]

#100986

[Multipart message — attachments visible in raw view] — view raw

Le jeudi 12 août 2021, 09:52:53 UTC Bastien Roucariès a écrit :
> Le mercredi 11 août 2021, 14:00:37 UTC Steve McIntyre a écrit :
> > On Tue, Aug 10, 2021 at 03:19:10PM -0700, Josh Triplett wrote:
> > >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.
> > >> 
> > >> I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi
> > >> )  and i686-uefi-none ?
> > 
> > As Simon says, *definitely* not *windows* here please! :-)
> > 
> > >I don't think GRUB's x86_64-efi is an architecture triplet, just a
> > >GRUB-specific target.
> > >
> > >UEFI is effectively an "operating system", insofar as it provides a
> > >runtime environment with some baseline properties and a set of system
> > >calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> > >since there is an OS of sorts.
> > >
> > >For that reason, Rust uses the target names "aarch64-unknown-uefi",
> > >"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> > >right names for these targets in other toolchains, as well.
> > 
> > Nod, agreed. I think that makes sense.
> 
> Ok thanks
> 
> For the triplet this will be :
> -  i686-unknown-uefi
> - x86_64-unknown-uefi
> Where should I push this triplet ?
> 
> Ant therefore we get the multiarch tupple:
> - i386-uefi
> - amd64-uefi
> If I am right ?
> I have added to https://wiki.debian.org/Multiarch/Tuples but I suppuse I
> should open a bug somewhere (dpkg ?)
I have changed the arch name, it will be:
uefi-i686
uefi-amd64
with multiarch tupple i686-uefi, x86_64-uefi

I think it is better in line with current kfreebsd pratice...

Bastien

> 
> Bastien
> 
> Bastien

[toc] | [prev] | [next] | [standalone]

#100990

[Multipart message — attachments visible in raw view] — view raw

Le jeudi 12 août 2021, 10:16:45 UTC Bastien Roucariès a écrit :
> Le jeudi 12 août 2021, 09:52:53 UTC Bastien Roucariès a écrit :
> > Le mercredi 11 août 2021, 14:00:37 UTC Steve McIntyre a écrit :
> > > On Tue, Aug 10, 2021 at 03:19:10PM -0700, Josh Triplett wrote:
> > > >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.
> > > >> 
> > > >> I suppose that it will be  x86_64-efi-none (or maybe
> > > >> x86_64-windows-efi
> > > >> )  and i686-uefi-none ?
> > > 
> > > As Simon says, *definitely* not *windows* here please! :-)
> > > 
> > > >I don't think GRUB's x86_64-efi is an architecture triplet, just a
> > > >GRUB-specific target.
> > > >
> > > >UEFI is effectively an "operating system", insofar as it provides a
> > > >runtime environment with some baseline properties and a set of system
> > > >calls. uefi definitely isn't a "vendor", and the OS shouldn't be "none"
> > > >since there is an OS of sorts.
> > > >
> > > >For that reason, Rust uses the target names "aarch64-unknown-uefi",
> > > >"i686-unknown-uefi", and "x86_64-unknown-uefi". Those seem like the
> > > >right names for these targets in other toolchains, as well.
> > > 
> > > Nod, agreed. I think that makes sense.
> > 
> > Ok thanks
> > 
> > For the triplet this will be :
> > -  i686-unknown-uefi
> > - x86_64-unknown-uefi
> > Where should I push this triplet ?
> > 
> > Ant therefore we get the multiarch tupple:
> > - i386-uefi
> > - amd64-uefi
> > If I am right ?
> > I have added to https://wiki.debian.org/Multiarch/Tuples but I suppuse I
> > should open a bug somewhere (dpkg ?)
> 
> I have changed the arch name, it will be:
> uefi-i686
> uefi-amd64
> with multiarch tupple i686-uefi, x86_64-uefi
> 
> I think it is better in line with current kfreebsd pratice...
Changed a new once after implementing debian arch-name to uefi-i386 will allow 
to use uefi-$(DEBARCH) in makefile
> 
> Bastien
> 
> > Bastien
> > 
> > Bastien

[toc] | [prev] | [next] | [standalone]

#101007

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.

Where <https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches>
comes to mind.

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. :)

> I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi  )  and 
> i686-uefi-none ? Note that grub use x86_64-efi

The vendor always gets ignored in the dpkg context.

Although is there really a need for a cross-compiler here, or is
something like -ffreestanding enough?

> I suppose we should register these triplet somewhere, and I suppose it is 
> config-patches@gnu.org ?

https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F

Thanks,
Guillem

[toc] | [prev] | [next] | [standalone]

#101011

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

[toc] | [prev] | [next] | [standalone]

#101013

[Multipart message — attachments visible in raw view] — view raw

Le vendredi 13 août 2021, 00:29:02 UTC Guillem Jover a écrit :
> 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.

Why ? If we build now a arch-all package and when the arch is up we could 
Break to the arch:all package. Normally it should work (or maybe I miss 
something)
> 
> Where <https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches>
> comes to mind.

Yes it is the same except that uefi is a full fledged arch with a sort of OS.  
But it will be nice to use the same thing

I volontuer to implement this stuff, it will allow to build for instance 
firmware to arm easilly. Do you have some pointer of how to implement ?

> 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. :)

Yes and no. In this case, clang use i686 as triplet and API is specified to be 
i686 only.
 
> > I suppose that it will be  x86_64-efi-none (or maybe x86_64-windows-efi  )
> >  and i686-uefi-none ? Note that grub use x86_64-efi
> 
> The vendor always gets ignored in the dpkg context.
> 
> Although is there really a need for a cross-compiler here, or is
> something like -ffreestanding enough?

It is more the freestanding but just a little bit more. I plan to create a 
spec file to gcc for helping and adding slowly stuff like hardenning library 
(for improving security of this beast) 


> > I suppose we should register these triplet somewhere, and I suppose it is
> > config-patches@gnu.org ?
> 
> https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_ar
> chitectures.3F
Ok will do, step by step.

> 
> Thanks,
> Guillem

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web