gnu-efi-discuss Mailing List for gnu-efi
Brought to you by:
noxorc
Menu
▾
▴
gnu-efi-discuss
You can subscribe to this list here.
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
(12) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(14) |
| 2023 |
Jan
(5) |
Feb
(6) |
Mar
(32) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
(15) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nigel C. <nc...@re...> - 2024-05-08 12:17:14
|
On 3/27/24 7:48 AM, Callum Farmer wrote: > > > On Tue, 26 Mar 2024, 17:54 Heinrich Schuchardt via Gnu-efi-discuss, > <gnu...@li...> wrote: > > On 3/25/24 11:06, Richard Hughes wrote: > > This has been part of fwupd-efi for a long time now. > > > > Also; I can't pretend to understand all this, so please review this > > carefully and let me know what you think. For those following along, > > I'm trying to unfork the fedora gnu-efi version of gnu-efi (99% > done), > > and also unfork the lds and .S parts of fwupd-efi that we use as a > > fallback. > > > > Richard. > > Hello Richard, > > Getting the different version of gnu-efi into line is a good idea. > > Could you, please, fork gnu-efi on > https://sourceforge.net/p/gnu-efi/code/ and create a merge request. > > > Migrated to GitHub since March 22 > (https://github.com/ncroxon/gnu-efi) > > Mainly for Nigel; We also could do with enabling GH Discussions so > this mailing list can also go aswell > (Reference: > https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/enabling-or-disabling-github-discussions-for-a-repository) Discussions are enabled on Github/gnu-efi. -Nigel > > > As .sbat sections are not in the PE/COFF and UEFI specifications the > commit message should provide some context, e.g. > > "Multiple projects including fwupd, shim, and GRUB use a CSV file > copied > to a section named .sbat for fine grained security control in a UEFI > secure boot environment. For details see > https://github.com/rhboot/shim/blob/main/SBAT.md." > > Your patch only modifies the linker scripts. Without modifying > ./gnuefi/crt0-efi-<arch>.S the .sbat section will be missing in the > section table. Without updating Make.rules no .sbat section data > will be > copied into the EFI binary. README.gnuefi should describe how to > build a > binary with .sbat data. > > Best regards > > Heinrich > > The only issue I have with this patch, is I believe there used to be > an issue with empty sections (if no SBAT data, the section will be > empty) with the UEFI loader, I don't know if it's been fixed > > Although SBAT is (mostly) always needed now (Secure Boot) so we could > just simply require it > > > > > _______________________________________________ > Gnu-efi-discuss mailing list > Gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnu-efi-discuss > > > Many thanks, > > Callum F > > > > > _______________________________________________ > Gnu-efi-discuss mailing list > Gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnu-efi-discuss |
|
From: Richard H. <hug...@gm...> - 2024-05-07 14:10:25
|
On Tue, 26 Mar 2024 at 17:54, Heinrich Schuchardt <xyp...@gm...> wrote: > Getting the different version of gnu-efi into line is a good idea. I think it's the only sane thing to do long term :) > As .sbat sections are not in the PE/COFF and UEFI specifications the > commit message should provide some context, e.g.> > "Multiple projects including fwupd, shim, and GRUB use a CSV file copied > to a section named .sbat for fine grained security control in a UEFI > secure boot environment. For details see > https://github.com/rhboot/shim/blob/main/SBAT.md." Fixed, thanks. > Your patch only modifies the linker scripts. Without modifying > ./gnuefi/crt0-efi-<arch>.S the .sbat section will be missing in the > section table. This was the bit I wasn't sure how to do, for instance, this is what fwupd does: diff --git a/gnuefi/crt0-efi-riscv64.S b/gnuefi/crt0-efi-riscv64.S index 712ed03..6350105 100644 --- a/gnuefi/crt0-efi-riscv64.S +++ b/gnuefi/crt0-efi-riscv64.S @@ -35,7 +35,7 @@ pe_header: .2byte 0 coff_header: .2byte 0x5064 // riscv64 - .2byte 4 // nr_sections + .2byte NR_SECTIONS // nr_sections .4byte 0 // TimeDateStamp .4byte 0 // PointerToSymbolTable .4byte 0 // NumberOfSymbols @@ -150,6 +150,20 @@ section_table: .2byte 0 // NumberOfLineNumbers .4byte 0x40000040 // Characteristics (section flags) +#ifdef USING_SBAT + .ascii ".sbat\0\0\0" + .4byte _sbat_vsize - ImageBase // VirtualSize + .4byte _sbat - ImageBase // VirtualAddress + .4byte _sbat_size - ImageBase // SizeOfRawData + .4byte _sbat - ImageBase // PointerToRawData + + .4byte 0 // PointerToRelocations (0 for executables) + .4byte 0 // PointerToLineNumbers (0 for executables) + .2byte 0 // NumberOfRelocations (0 for executables) + .2byte 0 // NumberOfLineNumbers (0 for executables) + .4byte 0x40000040 // Characteristics (section flags) +#endif + .text .globl _start .type _start,%function ...which means you have to set USING_SBAT and NR_SECTIONS in the build system. I'm wondering if this is the right way to do it; it seems having an empty section unconditionally (e.g. setting nr_sections to 5) might be okay, but does blow up the binary size by 4k for everyone. Maybe that's okay. > Without updating Make.rules no .sbat section data will be > copied into the EFI binary. Got it -- thanks. I'm using meson in fwupd-efi so I missed that. > README.gnuefi should describe how to build a > binary with .sbat data. Something like this perhaps? + .sbat + This section contains CSV data to specify the fine grained + security control of the UEFI secure boot environment. + To populate this, use objcopy: + + $ objcopy --remove-section=.sbat --add-section .sbat=sbat.csv \ + --set-section-flags=.sbom=contents,alloc,load,readonly,data \ + filename.exe Richard. |
|
From: Nigel C. <nc...@re...> - 2024-03-27 13:38:58
|
Enabled... https://github.com/ncroxon/gnu-efi/discussions -Nigel On 3/27/24 7:48 AM, Callum Farmer wrote: > > > On Tue, 26 Mar 2024, 17:54 Heinrich Schuchardt via Gnu-efi-discuss, > <gnu...@li...> wrote: > > On 3/25/24 11:06, Richard Hughes wrote: > > This has been part of fwupd-efi for a long time now. > > > > Also; I can't pretend to understand all this, so please review this > > carefully and let me know what you think. For those following along, > > I'm trying to unfork the fedora gnu-efi version of gnu-efi (99% > done), > > and also unfork the lds and .S parts of fwupd-efi that we use as a > > fallback. > > > > Richard. > > Hello Richard, > > Getting the different version of gnu-efi into line is a good idea. > > Could you, please, fork gnu-efi on > https://sourceforge.net/p/gnu-efi/code/ and create a merge request. > > > Migrated to GitHub since March 22 > (https://github.com/ncroxon/gnu-efi) > > Mainly for Nigel; We also could do with enabling GH Discussions so > this mailing list can also go aswell > (Reference: > https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/enabling-or-disabling-github-discussions-for-a-repository) > > > As .sbat sections are not in the PE/COFF and UEFI specifications the > commit message should provide some context, e.g. > > "Multiple projects including fwupd, shim, and GRUB use a CSV file > copied > to a section named .sbat for fine grained security control in a UEFI > secure boot environment. For details see > https://github.com/rhboot/shim/blob/main/SBAT.md." > > Your patch only modifies the linker scripts. Without modifying > ./gnuefi/crt0-efi-<arch>.S the .sbat section will be missing in the > section table. Without updating Make.rules no .sbat section data > will be > copied into the EFI binary. README.gnuefi should describe how to > build a > binary with .sbat data. > > Best regards > > Heinrich > > The only issue I have with this patch, is I believe there used to be > an issue with empty sections (if no SBAT data, the section will be > empty) with the UEFI loader, I don't know if it's been fixed > > Although SBAT is (mostly) always needed now (Secure Boot) so we could > just simply require it > > > > > _______________________________________________ > Gnu-efi-discuss mailing list > Gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnu-efi-discuss > > > Many thanks, > > Callum F > > > > > _______________________________________________ > Gnu-efi-discuss mailing list > Gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnu-efi-discuss |
|
From: Callum F. <gm...@op...> - 2024-03-27 11:48:52
|
On Tue, 26 Mar 2024, 17:54 Heinrich Schuchardt via Gnu-efi-discuss, < gnu...@li...> wrote: > On 3/25/24 11:06, Richard Hughes wrote: > > This has been part of fwupd-efi for a long time now. > > > > Also; I can't pretend to understand all this, so please review this > > carefully and let me know what you think. For those following along, > > I'm trying to unfork the fedora gnu-efi version of gnu-efi (99% done), > > and also unfork the lds and .S parts of fwupd-efi that we use as a > > fallback. > > > > Richard. > > Hello Richard, > > Getting the different version of gnu-efi into line is a good idea. > > Could you, please, fork gnu-efi on > https://sourceforge.net/p/gnu-efi/code/ and create a merge request. > Migrated to GitHub since March 22 (https://github.com/ncroxon/gnu-efi) Mainly for Nigel; We also could do with enabling GH Discussions so this mailing list can also go aswell (Reference: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/enabling-or-disabling-github-discussions-for-a-repository ) > As .sbat sections are not in the PE/COFF and UEFI specifications the > commit message should provide some context, e.g. > > "Multiple projects including fwupd, shim, and GRUB use a CSV file copied > to a section named .sbat for fine grained security control in a UEFI > secure boot environment. For details see > https://github.com/rhboot/shim/blob/main/SBAT.md." > > Your patch only modifies the linker scripts. Without modifying > ./gnuefi/crt0-efi-<arch>.S the .sbat section will be missing in the > section table. Without updating Make.rules no .sbat section data will be > copied into the EFI binary. README.gnuefi should describe how to build a > binary with .sbat data. > > Best regards > > Heinrich > The only issue I have with this patch, is I believe there used to be an issue with empty sections (if no SBAT data, the section will be empty) with the UEFI loader, I don't know if it's been fixed Although SBAT is (mostly) always needed now (Secure Boot) so we could just simply require it > > _______________________________________________ > Gnu-efi-discuss mailing list > Gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnu-efi-discuss Many thanks, Callum F > > |
|
From: Heinrich S. <xyp...@gm...> - 2024-03-26 17:54:31
|
On 3/25/24 11:06, Richard Hughes wrote: > This has been part of fwupd-efi for a long time now. > > Also; I can't pretend to understand all this, so please review this > carefully and let me know what you think. For those following along, > I'm trying to unfork the fedora gnu-efi version of gnu-efi (99% done), > and also unfork the lds and .S parts of fwupd-efi that we use as a > fallback. > > Richard. Hello Richard, Getting the different version of gnu-efi into line is a good idea. Could you, please, fork gnu-efi on https://sourceforge.net/p/gnu-efi/code/ and create a merge request. As .sbat sections are not in the PE/COFF and UEFI specifications the commit message should provide some context, e.g. "Multiple projects including fwupd, shim, and GRUB use a CSV file copied to a section named .sbat for fine grained security control in a UEFI secure boot environment. For details see https://github.com/rhboot/shim/blob/main/SBAT.md." Your patch only modifies the linker scripts. Without modifying ./gnuefi/crt0-efi-<arch>.S the .sbat section will be missing in the section table. Without updating Make.rules no .sbat section data will be copied into the EFI binary. README.gnuefi should describe how to build a binary with .sbat data. Best regards Heinrich |
|
From: Richard H. <hug...@gm...> - 2024-03-25 10:06:41
|
This has been part of fwupd-efi for a long time now. Also; I can't pretend to understand all this, so please review this carefully and let me know what you think. For those following along, I'm trying to unfork the fedora gnu-efi version of gnu-efi (99% done), and also unfork the lds and .S parts of fwupd-efi that we use as a fallback. Richard. |
|
From: Richard H. <hug...@gm...> - 2024-03-22 15:16:20
|
Hi all, I've been doing some license review of the Fedora package ahead of packaging 3.0.18 (thanks again!) -- and I'm wondering what the new SPDX license sting should be. I've come to the conclusion it should be: BSD-2-Clause AND BSD-2-Clause-Patent AND BSD-3-Clause AND BSD-4-Clause AND GPL-2.0-or-later AND GPL-2.0 Does this sound right? Thanks. Richard. |
|
From: Nigel C. <nc...@re...> - 2024-03-22 14:54:35
|
Github has the latest code. I will stop using sourceforge.net https://github.com/ncroxon/gnu-efi -Nigel On 3/22/24 7:15 AM, Richard Hughes wrote: > On Fri, 22 Mar 2024 at 10:04, Callum Farmer <gm...@op...> wrote: >> The GitHub migration stalled: >> https://github.com/ncroxon/gnu-efi/issues/1 > For what it's worth, github would be an amazing upgrade -- public CI, > and all that. > >> And then we could also do with a new release (3.0.18) > Very much so -- I'm planning to ship a snapshot in Fedora next week, > but a proper tarball would be so much nicer. > > Richard. > > > _______________________________________________ > Gnu-efi-discuss mailing list > Gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnu-efi-discuss > |
|
From: Nigel C. <nc...@re...> - 2024-03-22 13:42:56
|
Hello Callum, and Richard... Callum, both patchsets have been accepted and merged. Richard, new tarball (gnu-efi-3.0.18.tar.bz2) has been created and is available. -Nigel On 3/22/24 7:15 AM, Richard Hughes wrote: > On Fri, 22 Mar 2024 at 10:04, Callum Farmer <gm...@op...> wrote: >> The GitHub migration stalled: >> https://github.com/ncroxon/gnu-efi/issues/1 > For what it's worth, github would be an amazing upgrade -- public CI, > and all that. > >> And then we could also do with a new release (3.0.18) > Very much so -- I'm planning to ship a snapshot in Fedora next week, > but a proper tarball would be so much nicer. > > Richard. > > > _______________________________________________ > Gnu-efi-discuss mailing list > Gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnu-efi-discuss > |
|
From: Richard H. <hug...@gm...> - 2024-03-22 11:15:57
|
On Fri, 22 Mar 2024 at 10:04, Callum Farmer <gm...@op...> wrote: > The GitHub migration stalled: > https://github.com/ncroxon/gnu-efi/issues/1 For what it's worth, github would be an amazing upgrade -- public CI, and all that. > And then we could also do with a new release (3.0.18) Very much so -- I'm planning to ship a snapshot in Fedora next week, but a proper tarball would be so much nicer. Richard. |
|
From: Callum F. <gm...@op...> - 2024-03-22 10:03:51
|
Hey team, Any chance of reviewing the two pending pull requests: https://sourceforge.net/p/gnu-efi/code/merge-requests/ The GitHub migration stalled: https://github.com/ncroxon/gnu-efi/issues/1 And then we could also do with a new release (3.0.18) Many thanks, Callum Farmer (gmbr3 @ openSUSE) |
|
From: Nigel C. <nc...@re...> - 2024-03-21 14:22:59
|
Patch accepted commit bd864bda4c7ca7cb6753559cf69670378776d8e0 Author: Peter Jones <pj...@re...> Date: Mon Mar 18 13:30:16 2024 +0000 Make: make TOPDIR actually work and get rid of unused CDIR -Nigel On 3/18/24 9:31 AM, Richard Hughes wrote: > Original patch is by Peter Jones, lightly modified by me to apply to master. > > Richard. > > > _______________________________________________ > Gnu-efi-discuss mailing list > Gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnu-efi-discuss |
|
From: Nigel C. <nc...@re...> - 2024-03-21 14:22:15
|
Patch accepted commit a3772f2e053d2413ecd49ce302f608a9c9ee04d8 Author: Peter Jones <pj...@re...> Date: Mon Mar 18 13:16:17 2024 +0000 make: Make "make clean" use @ and rm -v everywhere -Nigel On 3/18/24 9:19 AM, Richard Hughes wrote: > This makes our "make clean" commands show what they've /removed/, > rather than what the shell code that will be run is. > > Original patch is by Peter Jones, lightly modified by me to apply to master. > > Richard. > > > _______________________________________________ > Gnu-efi-discuss mailing list > Gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnu-efi-discuss |
|
From: Nigel C. <nc...@re...> - 2024-03-21 14:21:58
|
Patch accepted commit 4d4cb5a2bc3aafa7e0f52c740af8b297c344b6b1 Author: Soop <seb...@ou...> Date: Mon Mar 18 13:09:11 2024 +0000 Make apps link against the local gnuefi and crt objects -Nigel On 3/18/24 9:12 AM, Richard Hughes wrote: > We've been building this in Fedora since 2015. > > Original patch is by Sebastian Osorio, lightly modified by me to apply > to master. > > Richard > > > _______________________________________________ > Gnu-efi-discuss mailing list > Gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnu-efi-discuss |
|
From: Richard H. <hug...@gm...> - 2024-03-18 13:32:01
|
Original patch is by Peter Jones, lightly modified by me to apply to master. Richard. |
|
From: Richard H. <hug...@gm...> - 2024-03-18 13:19:40
|
This makes our "make clean" commands show what they've /removed/, rather than what the shell code that will be run is. Original patch is by Peter Jones, lightly modified by me to apply to master. Richard. |
|
From: Richard H. <hug...@gm...> - 2024-03-18 13:12:29
|
We've been building this in Fedora since 2015. Original patch is by Sebastian Osorio, lightly modified by me to apply to master. Richard |
|
From: Andi K. <an...@fi...> - 2023-06-29 16:43:15
|
Hi gnu-efi experts, I'm developing a EFI run time driver using GNU efi 3.0.11 (-10 from FC37). I noticed that const relocations don't seem to be handled correctly, so something like "static const void *p = &symbol;" doesn't point to the correct address at run time. Another issue is that the BSS doesn't seem to be cleared. Am I doing something wrong here, or are these known restrictions? Build: cc -Wall -g -O1 -fPIE -mno-red-zone -ffreestanding -fno-stack-protector -fno-stack-check -c -o foo.o foo.c ... more source files ... ld -shared -Bsymbolic -L/usr/lib/gnuefi/x64 -T/usr/lib/gnuefi/x64/efi.lds /usr/lib/gnuefi/x64/crt0.o foo.o .. -o foo.so -lgnuefi -lefi objcopy -j .text -j .sdata -j .data -j .dynamic -j .dynsym -j .rel -j .rela -j .rel.* -j .rela.* -j .reloc --target efi-app-x86_64 --subsystem=12 foo.so foo.efi gcc 12.3.1 and binutils 2.38-27.fc37 Thanks, -Andi |
|
From: Richard H. <hug...@gm...> - 2023-03-28 19:18:14
|
On Tue, 28 Mar 2023 at 18:06, Callum Farmer <gm...@op...> wrote: > Not needed post https://sourceforge.net/p/gnu-efi/code/ci/1e0055069400179726858e472591ca5ac334120b/ Great news, thanks! Richard. |
|
From: Callum F. <gm...@op...> - 2023-03-28 17:05:52
|
On 3/28/23 14:26, Richard Hughes wrote: > Newer gnu ld complains about RWX segment maps, and since we build with > "--fatal-warnings" we get the following: > > ld -nostdlib --warn-common --no-undefined --fatal-warnings \ > --build-id=sha1 -shared -Bsymbolic \ > -L/builddir/build/BUILD/gnu-efi-3.0.9//apps/../aa64/lib \ > -L/builddir/build/BUILD/gnu-efi-3.0.9//apps/../aa64/gnuefi \ > /builddir/build/BUILD/gnu-efi-3.0.9//apps/../aa64/gnuefi/crt0-efi-aarch64.o > \ > --defsym=EFI_SUBSYSTEM=0xa t.o -o t.so -lefi -lgnuefi \ > /usr/lib/gcc/aarch64-redhat-linux/13/libgcc.a \ > -T /builddir/build/BUILD/gnu-efi-3.0.9//apps/../gnuefi/elf_aarch64_efi.lds > ld: warning: t.so has a LOAD segment with RWX permissions > > Since the final linked binary will be PE, rather than ELF, and won't > even *have* segment maps, this should be safe to just disable. > > This patch adds "--no-warn-rwx-segments" to the ld command lines. Not needed post https://sourceforge.net/p/gnu-efi/code/ci/1e0055069400179726858e472591ca5ac334120b/ Many thanks, Callum F |
|
From: Heinrich S. <xyp...@gm...> - 2023-03-28 16:35:03
|
On 3/28/23 14:26, Richard Hughes wrote:
> Newer gnu ld complains about RWX segment maps, and since we build with
> "--fatal-warnings" we get the following:
>
> ld -nostdlib --warn-common --no-undefined --fatal-warnings \
> --build-id=sha1 -shared -Bsymbolic \
> -L/builddir/build/BUILD/gnu-efi-3.0.9//apps/../aa64/lib \
> -L/builddir/build/BUILD/gnu-efi-3.0.9//apps/../aa64/gnuefi \
> /builddir/build/BUILD/gnu-efi-3.0.9//apps/../aa64/gnuefi/crt0-efi-aarch64.o
> \
> --defsym=EFI_SUBSYSTEM=0xa t.o -o t.so -lefi -lgnuefi \
> /usr/lib/gcc/aarch64-redhat-linux/13/libgcc.a \
> -T /builddir/build/BUILD/gnu-efi-3.0.9//apps/../gnuefi/elf_aarch64_efi.lds
> ld: warning: t.so has a LOAD segment with RWX permissions
>
> Since the final linked binary will be PE, rather than ELF, and won't
> even *have* segment maps, this should be safe to just disable.
>
> This patch adds "--no-warn-rwx-segments" to the ld command lines.
Please, don't.
Having RWX segments is a security issue. Code segments must not be
writable. Some firmware rejects to load such code. E.g. I could not load
such a binary on the Lenovo X13s and had to fix building the binaries in
U-Boot.
Cf. U-Boot commit
d7ddeb66a6ce ("efi_loader: fix building aarch64 EFI binaries")
and following.
The correct approach is to adjust the loader script to put non-static
data into a different section than the code and to make the .text
section RX.
Best regards
Heinrich
>
> Signed-off-by: Peter Jones <pj...@re...>
>
> Richard.
|
|
From: Richard H. <hug...@gm...> - 2023-03-28 15:36:09
|
On Tue, 28 Mar 2023 at 14:08, Nigel Croxon <nc...@re...> wrote: > I don't have a new gnu ld command. This patch causes failures to build > the package. No worries, good QA. Would you like me to rework this patch to check if the argument is supported, or just patch downstream? Thanks. Richard |
|
From: Richard H. <hug...@gm...> - 2023-03-28 14:14:12
|
This makes the normal DESTDIR= variable work on the command line, and makes relative paths always relative to the top-level directory. Signed-off-by: Peter Jones <pj...@re...> We've been using this patch in Fedora since 2019. Original patch is by Peter Jones, sent with permission. Richard |
|
From: Richard H. <hug...@gm...> - 2023-03-28 14:12:20
|
Right now whenever we have shell commands with loops, errors in the middle are accidentally ignored, and make continues to process commands. This adds "set -e" to all of those, so they'll propagate back up. Signed-off-by: Peter Jones <pj...@re...> Original patch is by Peter Jones, lightly modified by me to apply to master. Richard |
|
From: Richard H. <hug...@gm...> - 2023-03-28 14:10:14
|
This makes us use CFLAGS when trying to find libgcc, so we don't get the one with the wrong endian or float ABI. Signed-off-by: Peter Jones <pj...@re...> Original patch is by Peter Jones, sent with permission. Richard. |
