Looks after switch to meson the build is completely borked on anything but amd64. I'll collect upload logs and dump it here.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=36674d2c08d09829f2527026517c4d015ec5efb6 commit 36674d2c08d09829f2527026517c4d015ec5efb6 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2020-05-02 16:34:35 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2020-05-02 16:36:46 +0000 Revert "sys-apps/flashrom: switch to building with meson" Turns out that not only do upstream meson scripts require patching to handle all programmers flashrom supports, they also only appear to work on amd64. Sigh. This reverts commit b5a312d32873362067980b2a02886a4b79d08ca6. Bug: https://bugs.gentoo.org/720210 Signed-off-by: Marek Szuba <marecki@gentoo.org> .../flashrom/files/flashrom-1.2_meson-fixes.patch | 263 --------------------- sys-apps/flashrom/flashrom-1.2-r2.ebuild | 147 ------------ 2 files changed, 410 deletions(-)
(but please still upload the logs, I want to see what is going on)
first of all we'll need some masking for some flags on arches. but that can be fixed easily, I'll check ppc64 and mask unsupported flags. meson as implemented in flashrom, does not have friendly messages they I try to build something that's not supported on ppc64 for example old ebuild, fails at initial make, very early and clearly: > The following features are unavailable on your machine: CONFIG_INTERNAL=yes CONFIG_ATAPROMISE=yes new ebuild, fails at build time: > FAILED: flashrom@sha/satamv.c.o > powerpc64le-unknown-linux-gnu-gcc -Iflashrom@sha -I. -I../flashrom-v1.2 -I/usr/include/libftdi1 -I/usr/include/libusb-1.0 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 > -std=c99 -Wwrite-strings -Wno-unused-parameter -Wno-address-of-packed-member -Wno-missing-braces -D_DEFAULT_SOURCE -D_POSIX_C_SOURCE -D_BSD_SOURCE '-DFLASHROM_VERSION="v1.2"' -DHAVE_CLOCK_GETTIME=1 -DHAVE_STRNLEN=1 -DHAVE_UTSNAME=1 -mcpu=power9 -O2 -frecord-gcc-switches -fdiagnostics-show-option -fPIC -DCONFIG_ATAVIA=1 -DCONFIG_BUSPIRATE_SPI=1 -DCONFIG_CH341A_SPI=1 -DCONFIG_DEDIPROG=1 -DCONFIG_DEVELOPERBOX_SPI=1 -DCONFIG_DIGILENT_SPI=1 -DCONFIG_DRKAISER=1 -DCONFIG_DUMMY=1 -DCONFIG_FT2232_SPI=1 -DHAVE_FT232H=1 -DCONFIG_GFXNVIDIA=1 -DCONFIG_INTERNAL=1 -DCONFIG_INTERNAL_DMI=1 -DCONFIG_IT8212=1 -DCONFIG_LINUX_MTD=1 -DCONFIG_LINUX_SPI=1 -DCONFIG_NICINTEL=1 -DCONFIG_NICINTEL_EEPROM=1 -DCONFIG_NICINTEL_SPI=1 -DCONFIG_OGP_SPI=1 -DCONFIG_PICKIT2_SPI=1 -DCONFIG_PONY_SPI=1 -DCONFIG_SATAMV=1 -DCONFIG_SERPROG=1 -DCONFIG_USBBLASTER_SPI=1 -DCONFIG_STLINKV3_SPI=1 -DCONFIG_BITBANG_SPI=1 -DNEED_PCI=1 -MD -MQ 'flashrom@sha/satamv.c.o' -MF 'flashrom@sha/satamv.c.o.d' -o 'flashrom@sha/satamv.c.o' -c ../flashrom-v1.2/satamv.c > ../flashrom-v1.2/satamv.c:192:2: error: #error PCI port I/O access is not supported on this architecture yet. > 192 | #error PCI port I/O access is not supported on this architecture yet. > | ^~~~~ seems like meson integration is not feature complete yet. in next messages I'll upload build logs.
Created attachment 635752 [details] USE="-atapromise -internal -satasii" next test USE="-atapromise -internal" ebuild flashrom-1.2-r1.ebuild clean install builds fine on ppc64. but meson is completely borked. first of all, it also requires setting USE=-satasii" and fails like this
if I try to build with USE='-*' it fails with > meson.build:314:3: ERROR: Unknown variable "config_bitbang_spi".
Created attachment 635754 [details] USE="-gfxnvidia -nicintel -nicintel-eeprom -nicintel-spi -satasii -internal -atapromise" and here's a falure with USE="-gfxnvidia -nicintel -nicintel-eeprom -nicintel-spi -satasii -internal -atapromise" looks like it does not see it's own symbols, for some reason it does not happen on amd64
on arm64 same story, needs some flags masked as CONFIG_INTERNAL=yes CONFIG_ATAPROMISE=yes not supported on arm64, at least according to upstream check.
and if I build as USE="-internal -atapromise " ebuild flashrom-1.2-r1.ebuild clean install it's fine, installs and works. but if I disable as many chips as possible, meson one still fails /usr/lib/gcc/aarch64-unknown-linux-gnu/9.2.0/../../../../aarch64-unknown-linux-gnu/bin/ld: flashrom@sha/atavia.c.o: in function `atavia_init': atavia.c:(.text+0x408): undefined reference to `rget_io_perms' /usr/lib/gcc/aarch64-unknown-linux-gnu/9.2.0/../../../../aarch64-unknown-linux-gnu/bin/ld: flashrom@sha/drkaiser.c.o: in function `drkaiser_chip_readb': drkaiser.c:(.text+0x10): undefined reference to `mmio_le_readb' /usr/lib/gcc/aarch64-unknown-linux-gnu/9.2.0/../../../../aarch64-unknown-linux-gnu/bin/ld: flashrom@sha/drkaiser.c.o: in function `drkaiser_chip_writeb': drkaiser.c:(.text+0x28): undefined reference to `mmio_le_writeb' /usr/lib/gcc/aarch64-unknown-linux-gnu/9.2.0/../../../../aarch64-unknown-linux-gnu/bin/ld: flashrom@sha/drkaiser.c.o: in function `drkaiser_init': drkaiser.c:(.text+0x3c): undefined reference to `rget_io_perms' /usr/lib/gcc/aarch64-unknown-linux-gnu/9.2.0/../../../../aarch64-unknown-linux-gnu/bin/ld: drkaiser.c:(.text+0xa8): undefined reference to `rphysmap' /usr/lib/gcc/aarch64-unknown-linux-gnu/9.2.0/../../../../aarch64-unknown-linux-gnu/bin/ld: flashrom@sha/it8212.c.o: in function `it8212_chip_readb':
I don't really want to dive into meson files, but to me it looks like meson does not properly track dependencies between different modules and fails to link/pass flags. also it seems meson files are way stricter about which programmers work on which archtecture (incorrectly) and fail, yet build fine on old build system.
Fun times, now Makefile-based builds have begun to decay. Looks like it will be up to us to fix Meson scripts unless we want to continue messing with the former.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b97c59e62c6ea7ebc5a5c8f032b65420b8e75ff3 commit b97c59e62c6ea7ebc5a5c8f032b65420b8e75ff3 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2020-11-10 15:33:29 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2020-11-10 15:49:18 +0000 sys-apps/flashrom-1.2-r3: support building without bitbang_spi back-end In meson.build, config_bitbang_spi would be set to true in the event of the user having enabled any of the programmers requiring it - but *left undefined* otherwise. Initialise it to false so that even when no such programmers are enable, the 'if config_bitbang_spi' test does not produce an error. Bug: https://bugs.gentoo.org/720210 Signed-off-by: Marek Szuba <marecki@gentoo.org> .../flashrom/files/flashrom-1.2_meson-fixes.patch | 23 +++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=57831362bf329c007501691ba0bdf80f55ccfbe8 commit 57831362bf329c007501691ba0bdf80f55ccfbe8 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2020-11-10 15:19:08 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2020-11-10 15:49:14 +0000 sys-apps/flashrom-1.2-r3: fix satamv/satasii USE-flag mixup I accidentally mixed the two up, i.e. USE=satamv controlled config_satasii and the other way around. Whoopsie. Bug: https://bugs.gentoo.org/720210 Signed-off-by: Marek Szuba <marecki@gentoo.org> sys-apps/flashrom/flashrom-1.2-r3.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=46619bab75eea621eae5dba53d0c5e11c0263c3b commit 46619bab75eea621eae5dba53d0c5e11c0263c3b Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2020-11-10 16:20:29 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2020-11-10 16:26:07 +0000 sys-apps/flashrom-1.2-r3: fix raw-access dependencies This should allow Meson to successfully build flashrom without rayer-spi support but with any of the other drivers requiring raw access to hardware. Bug: https://bugs.gentoo.org/720210 Signed-off-by: Marek Szuba <marecki@gentoo.org> .../flashrom/files/flashrom-1.2_meson-fixes.patch | 34 ++++++++++++++++------ 1 file changed, 25 insertions(+), 9 deletions(-)
I think we might at last be good to go! Unfortunately I still haven't got access to any non-amd64 Gentoo boxes so could you perhaps try 1.2-r3 (must be unmasked) on some of the systems which previously caused problems?
(In reply to Marek Szuba from comment #13) > I think we might at last be good to go! Unfortunately I still haven't got > access to any non-amd64 Gentoo boxes so could you perhaps try 1.2-r3 (must > be unmasked) on some of the systems which previously caused problems? At least fwupd builds and runs now with flashrom forced. Nice job :)
sure, I can test arm64 and ppc64 and yeah, good news for fwupd
still fails on ppc64. looks like it needs -std=gnu99 and not -std=c99 on ppc64 , as asm is non-standard extension, which is not allowed in bare c99. [6/88] powerpc64le-unknown-linux-gnu-gcc -Ilibflashrom.so.1.0.0.p -I. -I../flashrom-v1.2 -I/usr/include/libftdi1 -I/usr/include/libusb-1.0 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wwrite-strings -Wno-unused-parameter -Wno-address-of-packed-member -Wno-m issing-braces -D_DEFAULT_SOURCE -D_POSIX_C_SOURCE -D_BSD_SOURCE '-DFLASHROM_VERSION="v1.2"' -DHAVE_CLOCK_GETTIME=1 -DHAVE_STRNLEN=1 -DHAVE_UTSNAME=1 -O2 -mcpu=power9 -ftree-vectorize -frecord-gcc-switches -fdiagnostics-show-option -fPIC -DCONFIG_BUSPIRATE_SPI=1 -DCONFIG_DUMMY=1 -DCONFIG_FT2232_SPI=1 -DHAVE_FT232H=1 -DCONFIG_IT8212=1 -DCONFIG_LINUX_MTD=1 -DCONFIG_LINUX_SPI=1 -DCONFIG_SATASII=1 -DCONFIG_SERPROG=1 -DNEED_RAW_ACCESS=1 -DNEED_PCI=1 -MD -MQ libflashrom.so.1.0.0.p/hwaccess.c.o -MF libflashrom.so.1.0.0.p/hwaccess.c.o.d -o libflashrom.so.1.0. 0.p/hwaccess.c.o -c ../flashrom-v1.2/hwaccess.c FAILED: libflashrom.so.1.0.0.p/hwaccess.c.o powerpc64le-unknown-linux-gnu-gcc -Ilibflashrom.so.1.0.0.p -I. -I../flashrom-v1.2 -I/usr/include/libftdi1 -I/usr/include/libusb-1.0 -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c99 -Wwrite-strings -Wno-unused-parameter -Wno-address-of-packed-member -Wno-missing- braces -D_DEFAULT_SOURCE -D_POSIX_C_SOURCE -D_BSD_SOURCE '-DFLASHROM_VERSION="v1.2"' -DHAVE_CLOCK_GETTIME=1 -DHAVE_STRNLEN=1 -DHAVE_UTSNAME=1 -O2 -mcpu=power9 -ftree-vectorize -frecord-gcc-switches -fdiagnostics-show-option -fPIC -DCONFIG_BUSPIRATE_SPI=1 -DCONFIG_DUMMY=1 -DCONF IG_FT2232_SPI=1 -DHAVE_FT232H=1 -DCONFIG_IT8212=1 -DCONFIG_LINUX_MTD=1 -DCONFIG_LINUX_SPI=1 -DCONFIG_SATASII=1 -DCONFIG_SERPROG=1 -DNEED_RAW_ACCESS=1 -DNEED_PCI=1 -MD -MQ libflashrom.so.1.0.0.p/hwaccess.c.o -MF libflashrom.so.1.0.0.p/hwaccess.c.o.d -o libflashrom.so.1.0.0.p/hwa ccess.c.o -c ../flashrom-v1.2/hwaccess.c ../flashrom-v1.2/hwaccess.c: In function 'sync_primitive': ../flashrom-v1.2/hwaccess.c:74:2: warning: implicit declaration of function 'asm' [-Wimplicit-function-declaration] 74 | asm("eieio" : : : "memory"); | ^~~ ../flashrom-v1.2/hwaccess.c:74:13: error: expected ')' before ':' token 74 | asm("eieio" : : : "memory"); | ^~ | )
still fails on arm64 because it tries to build satamv looking at configure this seems wrong $(meson_use satasii config_satamv) $(meson_use satamv config_satasii) probably should be flipped =) I see masks in profile, so it should work.
for ppc64 (and prob ppc) append-cflags '-std=gnu99' is working ok. but this really should be upstream.
and if you need access to ppc64 boxen, lmk. I can provide. sam can provide access to arm/arm64 I think, but ask him for details if it's ready.
(In reply to Georgy Yakovlev from comment #17) > still fails on arm64 because it tries to build satamv > > looking at configure this seems wrong > > $(meson_use satasii config_satamv) > $(meson_use satamv config_satasii) > > probably should be flipped =) > I see masks in profile, so it should work. This got fixed by commit 57831362bf329c007501691ba0bdf80f55ccfbe8 (as mentioned above) so it looks like your tree was not up to date, could you try again?
(In reply to Marek Szuba from comment #20) > (In reply to Georgy Yakovlev from comment #17) > > > still fails on arm64 because it tries to build satamv > > > > looking at configure this seems wrong > > > > $(meson_use satasii config_satamv) > > $(meson_use satamv config_satasii) > > > > probably should be flipped =) > > I see masks in profile, so it should work. > > This got fixed by commit 57831362bf329c007501691ba0bdf80f55ccfbe8 (as > mentioned above) so it looks like your tree was not up to date, could you > try again? indeed, arm64 machine looks fine now, only it had tree outdated. ppc64 c99 problem is still there, i checked in on updated tree.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f3188587b9239347c58e9662ab903b2d929038b2 commit f3188587b9239347c58e9662ab903b2d929038b2 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2020-11-11 12:27:23 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2020-11-11 12:46:39 +0000 sys-apps/flashrom-1.2-r3: meson: change c_std to from c99 to gnu99 Required on ppc64 (at least) due to the use of asm() in raw-hw-access code. Interestingly enough, there is no mention of either gnu99 or c99 anywhere in the Makefile so it might have worked by pure chance there. Closes: https://bugs.gentoo.org/720210 Signed-off-by: Marek Szuba <marecki@gentoo.org> sys-apps/flashrom/files/flashrom-1.2_meson-fixes.patch | 9 +++++++++ 1 file changed, 9 insertions(+)
I think if no standard is requested explicitly, gcc decides itself, that can explain why it worked in Makefile. I confirm ppc64 issue is fixed, thanks =)
https://github.com/flashrom/flashrom/pull/155 looks it's the right way of fixing asm issue, but I see you already discuss it upstream.
