x86_64-pc-linux-gnu-gcc -O2 -pipe -march=native -DCHROMEOS_ENVIRONMENT -Wall -DNDEBUG -MMD -MF /var/tmp/portage/sys-boot/vboot-utils-72_p20181229/work/build/host/lib/util_misc.o.d -fPIE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_EXECINFO_H -DHAVE_LIBZIP -Ifirmware/include -Ifirmware/lib/include -Ifirmware/lib/cgptlib/include -Ifirmware/lib/cryptolib/include -Ifirmware/lib/tpm_lite/include -Ifirmware/2lib/include -Ifirmware/lib20/include -Ihost/include -Ihost/lib/include -Ihost/lib21/include -Ifirmware/lib21/include -c -o /var/tmp/portage/sys-boot/vboot-utils-72_p20181229/work/build/host/lib/util_misc.o host/lib/util_misc.c In file included from host/lib/util_misc.c:21: host/include/openssl_compat.h:16:20: error: static declaration of ‘RSA_get0_key’ follows non-static declaration static inline void RSA_get0_key(const RSA *rsa, const BIGNUM **n, ^~~~~~~~~~~~ In file included from host/lib/util_misc.c:9: ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-desktop-gnome_libressl_20190218-073051 ------------------------------------------------------------------- Please see the tracker bug for details. gcc-config -l: [1] x86_64-pc-linux-gnu-8.2.0 * Available Python interpreters, in order of preference: [1] python3.7 [2] python3.6 [3] python2.7 (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) [2] ruby25 (with Rubygems) [3] ruby26 (with Rubygems) * Available Rust versions: [1] rust-1.32.0 * java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.10.0 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm emerge -qpvO sys-boot/vboot-utils [ebuild N ] sys-boot/vboot-utils-72_p20181229 USE="libressl -minimal -static"
Created attachment 566082 [details] emerge-info.txt
Created attachment 566084 [details] emerge-history.txt
Created attachment 566086 [details] environment
Created attachment 566088 [details] etc.portage.tbz2
Created attachment 566090 [details] logs.tbz2
Created attachment 566092 [details] sys-boot:vboot-utils-72_p20181229:20190222-043959.log
Created attachment 566218 [details, diff] openssl's changes to v1.1 give us easy if statements to find. builds on amd64.
builds, that is, with a patch.
I'm not sure if its relevant... but this patch seems best applied by the ebuild in the "src_prepare" section, rather than in a PATCHES list.
Same issue on armv7a-unknown-linux-musleabihf. pagorman's patch only works after reverting https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=db7f353c9db529295c7c1fa1aa66751bbc9c1594
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c24cbd37c6d967028dcb5ed93568b6da56eecda0 commit c24cbd37c6d967028dcb5ed93568b6da56eecda0 Author: Jory Pratt <anarchy@gentoo.org> AuthorDate: 2019-06-13 01:52:17 +0000 Commit: Jory Pratt <anarchy@gentoo.org> CommitDate: 2019-06-13 01:52:40 +0000 sys-boot/vboot-utils: fix libressl support, musl dep fix Closes: https://bugs.gentoo.org/678594 Closes: https://bugs.gentoo.org/687820 Package-Manager: Portage-2.3.67, Repoman-2.3.14 Signed-off-by: Jory Pratt <anarchy@gentoo.org> .../vboot-utils/files/vboot-utils-72_p20181229-libressl.patch | 11 +++++++++++ ...72_p20181229.ebuild => vboot-utils-72_p20181229-r1.ebuild} | 2 ++ 2 files changed, 13 insertions(+)
it is still an issue at unstable amd64 tinderbox image 17.1-desktop-gnome-systemd_20190608-211904
Created attachment 579734 [details] emerge-info.txt
Created attachment 579736 [details] emerge-history.txt
Created attachment 579738 [details] environment
Created attachment 579740 [details] etc.portage.tbz2
Created attachment 579742 [details] logs.tbz2
Created attachment 579744 [details] sys-boot:vboot-utils-72_p20181229-r1:20190613-180250.log
For me (musl, unstable arm) the libressl support is fixed by that commit. (In reply to Toralf Förster from comment #14) > Created attachment 579736 [details] > emerge-history.txt Irrespective of this bug something seems to be wrong with that attachment, I don't think it tells what it should tell.
Created attachment 579770 [details] emerge --info
(In reply to Alpha Bravo from comment #19) > For me (musl, unstable arm) the libressl support is fixed by that commit. > > (In reply to Toralf Förster from comment #14) > > Created attachment 579736 [details] > > emerge-history.txt > Irrespective of this bug something seems to be wrong with that attachment, I > don't think it tells what it should tell. indeed fixed by https://github.com/toralf/tinderbox/commit/b944957713fa999aee8b94d7fe87ecc1a3ae0d63
FWIW it fails here at different amd64 tinderbox images, last image was: 17.1-systemd_20190614-051827
On AArch64 it fails, too.
Problems might be solved with the ebuild / version bump from Bug #688396, feel free to test.
Indeed, the vboot-utils-76.ebuild plus musl patch works for me on arm/amd64 with glibc or musl.
I've hit the same issue when compiling without the libressl USE flag. The problem with the patch in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c24cbd37c6d967028dcb5ed93568b6da56eecda0 is that when LIBRESSL_VERSION_NUMBER is unset, the condition #if OPENSSL_VERSION_NUMBER < 0x10100000L || LIBRESSL_VERSION_NUMBER < 0x2080000L always evaluates to true. Changing it to #if OPENSSL_VERSION_NUMBER < 0x10100000L || (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x2080000L) fixes the issue on my system (but I haven't tested it with the libressl USE flag).
This is still broken without using an overlay; both the adjusted patch in comment #26 and vboot-utils-76 (with a musl patch) are viable fixes. If things are that stacked up I can push one or both of these...
Created attachment 596264 [details] new version ebuild
Created attachment 596266 [details] musl patch for vboot-utils-76
Maybe you could even push vboot-utils-79 from bug 688396, which has: * seen some clean-up * been fixed for building with USE="static" * comes with a patch (vboot-utils-79-libzip.patch) that should fix the implementation of the new "libzip" USE-flag, which isn't fully respected otherwise One issue with the vboot-utils-76.ebuild might be, that if USE="-minimal libzip", dev-libs/libzip will be listed two times in RDEPEND.
And regardless of the version I still can't obtain the source tarball directly from the SRC_URI, I have to manually download it - not sure as to why.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5e25b4aa1598f53a0712d6229df67f5564687285 commit 5e25b4aa1598f53a0712d6229df67f5564687285 Author: Alpha Bravo <aos@ungwana.de> AuthorDate: 2020-01-13 00:40:39 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-01-13 01:07:44 +0000 sys-boot/vboot-utils: Bump to version 80_p20200108 Closes: https://bugs.gentoo.org/688396 Closes: https://bugs.gentoo.org/687820 Closes: https://bugs.gentoo.org/678594 Package-Manager: Portage-2.3.84, Repoman-2.3.20 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-boot/vboot-utils/Manifest | 1 + .../files/vboot-utils-80-musl-fts.patch | 17 ++++ sys-boot/vboot-utils/metadata.xml | 5 +- .../vboot-utils/vboot-utils-80_p20200108.ebuild | 104 +++++++++++++++++++++ 4 files changed, 126 insertions(+), 1 deletion(-)
