Fail for me too, on amd64 builds at least.
> Am 12.10.2020 um 17:53 schrieb Chavdar Ivanov <ci4ic4%gmail.com@localhost>:
>
> Hi,
> Another xentools413 build failure. It has been failing for me the last
> two weeks or so, failing to build seabios, as follows:
> ....
> gmake[5]: Entering directory
> '/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/firmware'
> /usr/pkg/bin/gmake -C seabios-dir CC=gcc LD=ld PYTHON=python3.7
> EXTRAVERSION="-Xen" all;
> gmake[6]: Entering directory
> '/usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1'
> Linking out/rom.o
> ld -N -T out/romlayout32flat.lds out/rom16.strip.o
> out/rom32seg.strip.o out/code32flat.o -o out/rom.o
> ld: out/code32flat.o: in function `memmove':
> /usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/string.c:206:
> undefined reference to `memcpy'
> ld: out/code32flat.o: in function `const_read_file':
> /usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/romfile.c:116:
> undefined reference to `memcpy'
> ld: out/code32flat.o: in function `tpm_log_event':
> /usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/tcgbios.c:131:
> undefined reference to `memcpy'
> ld: /usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/tcgbios.c:134:
> undefined reference to `memcpy'
> ld: out/code32flat.o: in function `smm_save_and_copy':
> /usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/fw/smm.c:148:
> undefined reference to `memcpy'
> ld: out/code32flat.o:/usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1/./src/fw/smm.c:171:
> more undefined references to `memcpy' follow
> gmake[6]: *** [Makefile:186: out/rom.o] Error 1
> gmake[6]: Leaving directory
> '/usr/pkgsrc/sysutils/xentools413/work/seabios-rel-1.12.1'
> gmake[5]: *** [Makefile:138: subdir-all-seabios-dir] Error 2
> gmake[5]: Leaving directory
> '/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/firmware'
> gmake[4]: *** [/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/firmware/../../tools/Rules.mk:232:
> subdirs-all] Error 2
> gmake[4]: Leaving directory
> '/usr/pkgsrc/sysutils/xentools413/work/xen-4.13.1/tools/firmware'
>
> ....
>
> Wonder whether there is something to do with the switch to gcc9? If
> you try to build seabios on its own, it fails the same way.
>
probably also correlated to:
> revision 1.8
> date: 2020-08-27 10:22:33 +0200; author: bouyer; state: Exp; lines: +20 -6; commitid: 6EkLpnMUbS7p4GlC;
> Always use system-supplied IOCTL definitions, remove xen-provided
> include files.
> Build seabios and ipxe, they're needed by qemu-xen (ipxe not strictly
> needed but it's convenient to have)
> Switch default device model from qemu-xen-traditional to qemu-xen
> (the former being unmaintained)
> Add upstream patch for XSA335 security issue.
> Bump PKGREVISION.
>
but yes, it seems like the compile stage uses __builtin_memcpy which is nowadays inlined whereas the python / ldscript needs memcpy explicit.
./out/code32flat.o.objdump:198 .text.iomemcpy 00000046 00000000 00000000 00004182 2**0
./out/code32flat.o.objdump:00000000 l d .text.iomemcpy 00000000 .text.iomemcpy
./out/code32flat.o.objdump:00000000 l F .text.iomemcpy 00000046 iomemcpy
./out/code32flat.o.objdump:00000000 *UND* 00000000 memcpy
after applying the following patch, seabios 1.14 (sorry for that) builds just fine.
—
--- src/string.c.orig 2020-10-24 08:24:32.543813339 +0200
+++ src/string.c 2020-10-24 08:25:00.984982804 +0200
@@ -152,9 +152,6 @@
void *
#undef memcpy
memcpy(void *d1, const void *s1, size_t len)
-#if MODESEGMENT == 0
-#define memcpy __builtin_memcpy
-#endif
{
SET_SEG(ES, GET_SEG(SS));
void *d = d1;
—
Cheers
Oskar
Attachment:
signature.asc
Description: Message signed with OpenPGP