> On 2/6/19 11:44 AM, Joakim Tjernlund wrote: > > On Wed, 2019-02-06 at 11:34 -0800, H. Peter Anvin wrote: > > > > Great, that tree now against a somewhat old gnu-efi though. > > > > To build against >= 3.0.8 I need to do: > > #gnu-efi >= 3.0.8 has memset/memcpy defined causing multiple syms errors > > sed -i 's/LDFLAGS =/LDFLAGS = -z muldefs /' mk/efi.mk || die "sed muldefs failed" > > > > Should be a trivial fix by simply omitting those from the > syslinux-provided library functions on EFI. > > -hpa >All this has been already done in Debian Testing a couple of months ago (at least). The next step for Debian in this regard should probably be to test with gnu-efi 3.0.9 or newer, because the latter includes relevant patches already. More importantly, there are building problems in 6.04-pre2. Part of them have been already reported in this Syslinux Mailing List and in Debian's bug tracker too, with proposed patches. Example: boot: hdt.c32 Undef symbol FAIL: exp Failed to load libgpl.c32 Failed to load COM32 file hdt.c32 boot: Problems: binutils 2.31+, gcc 8+ For hints, see patches already applied in Debian, and additional proposed patches from "David Woodhouse" in the Syslinux Mailing List archives for 2018Aug. FWIW, Fedora 29 has not been able to include an updated package of Syslinux; the build failed. In short, F29 distributes the Syslinux package from F28. Therefore, it should not be a surprise that the new 6.04-pre2 has some (already-known) problems. Regards, Ady.
On Wed, 2019-02-06 at 20:31 +0000, Ady Ady via Syslinux wrote:> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > On 2/6/19 11:44 AM, Joakim Tjernlund wrote: > > > On Wed, 2019-02-06 at 11:34 -0800, H. Peter Anvin wrote: > > > > > > Great, that tree now against a somewhat old gnu-efi though. > > > > > > To build against >= 3.0.8 I need to do: > > > #gnu-efi >= 3.0.8 has memset/memcpy defined causing multiple syms errors > > > sed -i 's/LDFLAGS =/LDFLAGS = -z muldefs /' mk/efi.mk || die "sed muldefs failed" > > > > > > > Should be a trivial fix by simply omitting those from the > > syslinux-provided library functions on EFI. > > > > -hpa > > > > All this has been already done in Debian Testing a couple of months ago > (at least). The next step for Debian in this regard should probably be > to test with gnu-efi 3.0.9 or newer, because the latter includes > relevant patches already.Ahh, that would be great if these could be applied too.
Ady Ady
2019-Feb-07 16:51 UTC
[syslinux] 6.04-pre2, gnu-efi 3.0.8+, libgpl.c32 bug report. WAS: syslinux-6.04-pre2
> > > Should be a trivial fix by simply omitting those from the > > > syslinux-provided library functions on EFI. > > > > > > -hpa > > > > > > > All this has been already done in Debian Testing a couple of months ago > > (at least). The next step for Debian in this regard should probably be > > to test with gnu-efi 3.0.9 or newer, because the latter includes > > relevant patches already. > > Ahh, that would be great if these could be applied too. >>From Debian's git repo:https://salsa.debian.org/images-team/syslinux.git https://salsa.debian.org/images-team/syslinux/commits/debian/master https://salsa.debian.org/images-team/syslinux/commits/58d5e270a520da13a6 cd2ab9db0b235f1145d50a These are relevant patches already used in Debian: Description: Fix compatibility with new gnu-efi version * The VPrint definition is now part of the exports of gnu-efi * The EFI_PXE_BASE_CODE struct has been renamed to EFI_PXE_BASE_CODE_PROTOCOL * Update the longjump calls to fit the new declaration * Allow multiple definitions when linking the syslinux binary so the memset and memcpy symbols which are included by gnu-efi since 3.0.8 are ignored (we still use the definitions from syslinux) but linking succeeds The reason for that last one is: * gnu-efi compatibility patch: use memset and memcpy from syslinux instead of from gnu-efi - Using the memset and memcpy from gnu-efi causes some modules (e.g. vesamenu.c32) to fail with "Undef symbol FAIL: memset" And, once again, upstream git master head of gnu-efi has relevant patches _after_ 3.0.8. Whether they actually solved the memset and memcpy issues for Syslinux, that's for some capable developer to test/say. https://sourceforge.net/p/gnu-efi/code/ci/d34132e62f666904158c7ec2f1eef5 a9d5281c36/log/ git clone git://git.code.sf.net/p/gnu-efi/code gnu-efi-code or git clone https://git.code.sf.net/p/gnu-efi/code gnu-efi-code Additional relevant patches included in Debian: * Strip .note.gnu.property section from mbr.bin (added since binutils >= 2.31.1-2) to stay within size constraints (Closes: #906414). * Fix broken efi binaries when building with binutils >= 2.31 by patching the linker script. In addition, syslinux 6.04-pre2 and Debian's package, both fail, for example with hdt.c32: boot: hdt.c32 Undef symbol FAIL: exp Failed to load libgpl.c32 Failed to load COM32 file hdt.c32 boot: See: _ "syslinux-common: Undef symbol FAIL: exp in libgpl.c32 when trying to load hdt.c32" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918915 _ [syslinux] [PATCH 1/2] Add fabs() implementation https://www.syslinux.org/archives/2018-August/026158.html _ [syslinux] [PATCH 2/2] Add -ffreestanding to compiler flags https://www.syslinux.org/archives/2018-August/026159.html So, bintutils 2.31+, gcc 8+. I sincerely don't know how many times a bug has to be reported, or a patch has to be sent, in order to be actually noticed. Hopefully this time... Regards, Ady.