Bug#928386: syslinux: possible regression bug 'Undef symbol FAIL: memset'
On Sun, May 12, 2019 at 01:10:47PM +0200, Lukas Schwaighofer wrote: > I've confirmed the issue is fixed in backports version > 3:6.04~git20190206.bf6db5b4+dfsg1-1~bpo9+2. Looks like the "Closes:" > mechanism is not available for backports, so closing manually thank you for both, Lukas! > (also not > sure if setting the Version pseudo-header makes sense here since the BTS > does not know about backports versions anyways…). it surely doesnt hurt. :) -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#928386: syslinux: possible regression bug 'Undef symbol FAIL: memset'
Hi, On Mon, May 06, 2019 at 12:43:10AM +0200, Lukas Schwaighofer wrote: > Andreas Steinel wrote: > > In version 6.04~git20190206.bf6db5b4+dfsg1-1, the bug that was closed > > in 6.04~git20171011.af7e95c3+dfsg1-6 is back - at least in the 64-bit > > UEFI part, legacy works fine: thanks for the bug report, Andreas! > I've attached a modification of the 0005-gnu-efi-version-compatibility > patch. Instead of using `-zmuldefs` I'm stripping the memset and memcpy > symbols from gnu-efi so there are no longer any duplicate symbols. > Using that I was able to build a version without that bug for backports. thanks for the fix, Lukas! > Holger: Can you take care of updating the backports version? I've run > my little hacky regression-testing script on the modified backports > build and it passed all my tests. done. -- tschau, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#928386: syslinux: possible regression bug 'Undef symbol FAIL: memset'
Control: tags -1 + confirmed patch Hi Andreas, On Fri, 3 May 2019 14:21:06 +0200 Andreas Steinel wrote: > In version 6.04~git20190206.bf6db5b4+dfsg1-1, the bug that was closed > in 6.04~git20171011.af7e95c3+dfsg1-6 is back - at least in the 64-bit > UEFI part, legacy works fine: > > Full log is: > > Undef symbol FAIL: memset > Failed to load libcom32.c32 > Failed to load COM32 file vesamenu.c32 Thanks for your report. I've looked at it and can confirm that this error is back :( . The good news is only the backports version is affected and not the version in buster (CC-ing Holger who is the backports maintainer). The problem is that the syslinux.efi binary uses the memset and memcpy implementation from gnu-efi which are incompatible and cause the error above. It should use the implementation from syslinux instead. Since the linker has two symbols to choose from, I had added the `-zmuldefs` flag. My guess is that the linker from stretch picks the "wrong" symbol. I expected the linker would always pick the first one it encounters which would be the "right" symbol (and that's what happens in buster). I've attached a modification of the 0005-gnu-efi-version-compatibility patch. Instead of using `-zmuldefs` I'm stripping the memset and memcpy symbols from gnu-efi so there are no longer any duplicate symbols. Using that I was able to build a version without that bug for backports. Holger: Can you take care of updating the backports version? I've run my little hacky regression-testing script on the modified backports build and it passed all my tests. Regards Lukas Repack libefi.a to not contain the memset and memcpy symbols to make sure the implementation from syslinux is used and no multiple symbol definitions are present. --- efi/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/efi/Makefile +++ b/efi/Makefile @@ -43,8 +43,10 @@ fs/pxe/pxe.o fs/pxe/tftp.o fs/pxe/urlparse.o fs/pxe/dhcp_option.o \ fs/pxe/ftp.o fs/pxe/ftp_readdir.o fs/pxe/http.o fs/pxe/http_readdir.o) +LIBEFI_STRIPPED = $(objdir)/libefi_stripped.a + LIB_OBJS = $(addprefix $(objdir)/com32/lib/,$(CORELIBOBJS)) \ - $(LIBEFI) + $(LIBEFI_STRIPPED) CSRC = $(sort $(wildcard $(SRC)/*.c)) OBJS = $(subst $(SRC)/,,$(filter-out %wrapper.o, $(patsubst %.c,%.o,$(CSRC @@ -73,6 +75,13 @@ syslinux.so: $(OBJS) $(CORE_OBJS) $(LIB_OBJS) $(LD) $(LDFLAGS) --strip-debug -o $@ $^ -lgnuefi -lefi +$(LIBEFI_STRIPPED): $(LIBEFI) + cp $(LIBEFI) $(LIBEFI_STRIPPED) + ar x $(LIBEFI_STRIPPED) init.o + strip -N memset -N memcpy init.o + ar r $(LIBEFI_STRIPPED) init.o + rm init.o + # We need to rename the .hash section because the EFI firmware # linker really doesn't like it. # $(OBJCOPY) --rename-section .gnu.hash=.sdata,load,data,alloc $^ $@
Bug#928386: syslinux: possible regression bug 'Undef symbol FAIL: memset'
Package: syslinux Version: 3:6.04~git20190206.bf6db5b4+dfsg1-1~bpo9+1 Severity: important Dear Maintainer, In version 6.04~git20190206.bf6db5b4+dfsg1-1, the bug that was closed in 6.04~git20171011.af7e95c3+dfsg1-6 is back - at least in the 64-bit UEFI part, legacy works fine: Full log is: Undef symbol FAIL: memset Failed to load libcom32.c32 Failed to load COM32 file vesamenu.c32 -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages syslinux depends on: ii libc6 2.24-11+deb9u4 ii mtools 4.0.18-2+b1 Versions of packages syslinux recommends: ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-1~bpo9+1 Versions of packages syslinux suggests: pn dosfstools -- no debconf information Best regards, Andreas Steinel M.Sc. M.Sc. eXirius IT Dienstleistungen GmbH Juchem-Straße 24 | 66571 Eppelborn T +49 6881 5 0 | i...@exirius.de http://www.exirius.de Amtsgericht Saarbrücken HRB 12124 Geschäftsführer: Dipl.-Math. oec. Michael Royar
