I am building a Gentoo system for my ARM based Beaglebone Black from scratch using a toolchain setup with crossdev. Most packages in @system build fine, but a handful fail, including this one. More detailed error message below: >>> Configuring source in /usr/armv7a-pip-linux-gnueabi/tmp/portage/dev-libs/libgcrypt-1.8.2-r2/work/libgcrypt-1.8.2 ... * .arm: running multilib-minimal_abi_src_configure * econf: updating libgcrypt-1.8.2/build-aux/config.guess with /usr/share/gnuconfig/config.guess * econf: updating libgcrypt-1.8.2/build-aux/config.sub with /usr/share/gnuconfig/config.sub /usr/armv7a-pip-linux-gnueabi/tmp/portage/dev-libs/libgcrypt-1.8.2-r2/work/libgcrypt-1.8.2/configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=armv7a-pip-linux-gnueabi --mandir=/u sr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/libgcr ypt-1.8.2-r2 --htmldir=/usr/share/doc/libgcrypt-1.8.2-r2/html --libdir=/usr/lib --disable-dependency-tracking --enable-noexecstack --disable-O-flag-munging --disable-static --without-cap abilities GPG_ERROR_CONFIG=/usr/bin/armv7a-pip-linux-gnueabi-gpg-error-config [snip] checking for gpg-error-config... /usr/bin/armv7a-pip-linux-gnueabi-gpg-error-config checking for GPG Error - version >= 1.25... no configure: error: libgpg-error is needed. See ftp://ftp.gnupg.org/gcrypt/libgpg-error/ . !!! Please attach the following file when seeking support: !!! /usr/armv7a-pip-linux-gnueabi/tmp/portage/dev-libs/libgcrypt-1.8.2-r2/work/libgcrypt-1.8.2-.arm/config.log * ERROR: dev-libs/libgcrypt-1.8.2-r2::gentoo failed (configure phase): * econf failed Reproducible: Always Steps to Reproduce: 1.Create cross toolcain (crossdev -t armv7a-pip-linux-gnueabi) 2.Unpack latest portage snapshot into /usr/armv7a-pip-linux-gnueabi/usr 3.Update /usr/armv7a-pip-linux-gnueabi/etc/portage/make.profile symlink to point to ../../usr/portage/profiles/default/linux/arm/13.0/armv7a 4. sudo armv7a-pip-linux-gnueabi-emerge -a1v --noreplace --keep-going @system 5. repeat step 4 as necessary until emerge actually attempts to build dev-libs/libgcrypt-1.8.2-r2 Actual Results: dev-libs/libgcrypt-1.8.2-r2 compile fails Expected Results: dev-libs/libgcrypt-1.8.2-r2 succeeds I have successfully installed 113 of the 134 packages in @system. There are 5 failing compile and the remaining 19 cannot be compiled due to dependencies on the 5 failing ones. joey@akita ~$ eix --installed cross-armv7a-pip-linux-gnueabi/\* [I] cross-armv7a-pip-linux-gnueabi/binutils [1] Available versions: (2.25.1) 2.25.1-r1 (2.26.1) 2.26.1 (2.27) (~)2.27-r1 (2.28.1) 2.28.1 (2.29.1) 2.29.1-r1 (2.30) (~)2.30 (~)2.30-r1 (git) **9999 {(+)cxx doc multitarget (+)nls static-libs test vanilla zlib} Installed versions: 2.30-r1(2.30)(18:38:46 22/04/2018)(cxx nls -doc -multitarget -static-libs -test) Homepage: https://sourceware.org/binutils/ Description: Tools necessary to build programs [I] cross-armv7a-pip-linux-gnueabi/gcc [1] Available versions: (2.95.3) ~*2.95.3-r10^s (3.3.6) ~3.3.6-r1^s (3.4.6) 3.4.6-r2^s (4.0.4) **4.0.4^s (4.1.2) 4.1.2^s (4.2.4) (~)4.2.4-r1^s (4.3.6) 4.3.6-r1^s (4.4.7) 4.4.7^s (4.5.4) 4.5.4^s (4.6.4) 4.6.4^s (4.7.4) 4.7.4-r1^s (4.8.5) 4.8.5-r1^s (4.9.4) 4.9.4^s (5.4.0) 5.4.0-r4^s (6.4.0) 6.4.0^s 6.4.0-r1^s (7.2.0) (~)7.2.0^s (~)7.2.0-r1^s (7.3.0) (~)7.3.0^s (~)7.3.0-r1^s **7.3.0-r2^s {altivec awt boundschecking cilk +cxx d debug doc fixed-point +fortran gcj go graphite hardened jit libssp mpx mudflap multilib +nls nopie nossp +nptl objc objc++ objc-gc +openmp +pch pgo +pie regression-test +sanitize +ssp vanilla +vtv} Installed versions: 7.3.0-r1(7.3.0)^s(18:53:05 22/04/2018)(cxx fortran nls nptl openmp pch pie ssp -altivec -awt -cilk -debug -doc -fixed-point -gcj -go -graphite -hardened -jit -libssp -mpx -multilib -objc -objc++ -objc-gc -pgo -regression-test -sanitize -vanilla -vtv) Homepage: https://gcc.gnu.org/ Description: The GNU Compiler Collection [I] cross-armv7a-pip-linux-gnueabi/glibc [1] Available versions: (2.2) (~)2.18-r1^s 2.19-r1^s **2.19-r2^s 2.20-r2^s 2.21-r2^s 2.22-r4^s 2.23-r4^s (~)2.24-r4^s 2.25-r10^s 2.25-r11^s (~)2.26-r6^s **2.27-r1^s **9999^s {audit caps compile-locales debug doc gd hardened headers-only multilib nscd profile +rpc selinux suid systemtap vanilla} Installed versions: 2.26-r6(2.2)^s(18:47:14 22/04/2018)(caps -audit -debug -doc -gd -hardened -headers-only -multilib -nscd -profile -selinux -suid -systemtap -vanilla) Homepage: https://www.gnu.org/software/libc/ Description: GNU libc C library [I] cross-armv7a-pip-linux-gnueabi/linux-headers [1] Available versions: (*)2.4.33.3^bs (~*)2.4.36^bs 3.18^bs 4.4^bs (~)4.9^bs 4.13^bs (~)4.14^bs (~)4.15^bs (~)4.16^bs (~)4.16-r1^bs {headers-only} Installed versions: 4.16-r1^bs(18:44:15 22/04/2018)(-headers-only) Homepage: https://www.kernel.org/ https://www.gentoo.org/ Description: Linux system headers [1] "crossdev" /mnt/striped/opt/portage/crossdev Found 4 matches
The problem seems to be that libgcrypt is not taking into account $ROOT when looking for /usr/bin/armv7a-pip-linux-gnueabi-gpg-error-config. So it is looking for it on the build system instead of in the host system. See below: ===== joey@akita files$ cat ~/bin/pipenv #!/bin/bash export PORTAGE_CONFIGROOT=/usr/armv7a-pip-linux-gnueabi export ROOT=/usr/armv7a-pip-linux-gnueabi export SYSROOT=/usr/armv7a-pip-linux-gnueabi exec $* ====== joey@akita files$ ~/bin/pipenv equery files dev-libs/libgpg-error | grep gpg-error-config /usr/bin/armv7a-pip-linux-gnueabi-gpg-error-config /usr/bin/gpg-error-config joey@akita files$ ls -l /usr/bin/armv7a-pip-linux-gnueabi-gpg-error-config ls: cannot access '/usr/bin/armv7a-pip-linux-gnueabi-gpg-error-config': No such file or directory joey@akita files$ ls -l /usr/armv7a-pip-linux-gnueabi/usr/bin/armv7a-pip-linux-gnueabi-gpg-error-config -rwxr-xr-x 1 root root 2355 Apr 23 19:44 /usr/armv7a-pip-linux-gnueabi/usr/bin/armv7a-pip-linux-gnueabi-gpg-error-config
Full disclosure: I had to patch dev-libs/libgpg-error to get it to build in this cross environment. I ended up applying the patch I reference in https://bugs.gentoo.org/653912#c11. I think this is unrelated, since that patch was just about making libgpg-error find the right header file to include given the name of CHOST. In this package, it is looking for gpg-error-config using the right value for CHOST. It is just looking on the build system instead of correctly prepending $ROOT when looking for that file.
Created attachment 528334 [details] output of sudo armv7a-pip-linux-gnueabi-emerge --info
Created attachment 528336 [details] output of sudo emerge --info
Created attachment 528338 [details] build.log
Created attachment 528340 [details] build-.arm.log
Created attachment 528342 [details] eclass-debug.log
Created attachment 528344 [details] environment
Created attachment 528346 [details] config.log
Created attachment 528348 [details] configure
Created attachment 528350 [details] autoheader.out
Created attachment 528352 [details] automake.out
Created attachment 528354 [details] autoconf.out
Created attachment 528356 [details] aclocal.out
Created attachment 528358 [details] libtoolize.out
Created attachment 528360 [details, diff] libtool-elt.patch
I am encountering this bug also. Note since you brought up the libgpg-error patch I did not go that route. I built my toolchain as arm-linux-gnueabihf which breezed right past the issue on that other bug. Did your libtool patch work for you? I'm using glibc on my end looks like I'll need to make a few tweaks.
(In reply to Ryan James from comment #17) > I am encountering this bug also. Note since you brought up the libgpg-error > patch I did not go that route. I built my toolchain as arm-linux-gnueabihf > which breezed right past the issue on that other bug. > > Did your libtool patch work for you? I'm using glibc on my end looks like > I'll need to make a few tweaks. I tried to go the route you went before I fully understood the libgpg-error bug. I tried building my toolchain as arm-pip-linux-gnueabihf (would not have worked around the libgpg-error bug), but the toolchain build itself failed when trying to build glibc with the stage1. It looked like it didn't like the "arm" part. Anyway it's working now so I'm not going to mess with it! Which libtool patch are you talking about? For this package? The libtool-elt patch attached here must be part of the package in portage...because I didn't add it.
(In reply to Ryan James from comment #17) > I am encountering this bug also. Note since you brought up the libgpg-error > patch I did not go that route. I built my toolchain as arm-linux-gnueabihf > which breezed right past the issue on that other bug. > > Did your libtool patch work for you? I'm using glibc on my end looks like > I'll need to make a few tweaks. I just sent you an email about cross building an ARM system on Gentoo that's not directly related to this bug.
Created attachment 528372 [details, diff] diff of ebuild that fixes the problem I was able to modify the ebuild to make it work properly in a cross environment. I just changed ${EPREFIX} to ${EROOT}. This should work for either cross or prefix Gentoo. See https://wiki.gentoo.org/wiki/Project:Prefix/Technical_Documentation#EPREFIX_variable
(In reply to Joe Harvell from comment #18) > (In reply to Ryan James from comment #17) > > I am encountering this bug also. Note since you brought up the libgpg-error > > patch I did not go that route. I built my toolchain as arm-linux-gnueabihf > > which breezed right past the issue on that other bug. > > > > Did your libtool patch work for you? I'm using glibc on my end looks like > > I'll need to make a few tweaks. > > I tried to go the route you went before I fully understood the libgpg-error > bug. > I tried building my toolchain as arm-pip-linux-gnueabihf (would not have > worked around the libgpg-error bug), but the toolchain build itself failed > when trying to build glibc with the stage1. It looked like it didn't like > the "arm" part. Anyway it's working now so I'm not going to mess with it! > > Which libtool patch are you talking about? For this package? The > libtool-elt patch attached here must be part of the package in > portage...because I didn't add it. Correcton. I had tried to build the toolchain as armv7-pip-linux-gnueabihf, not arm-pip-linux-gnueabihf.
Thanks! But we are downstream we do not fork upstream. Please workout with upstream to embed this or any other solution. Once merged downstream will be follow.
Alon, the patch is to the ebuild. Are you saying that upstream maintains the ebuild?
(In reply to Joe Harvell from comment #23) > Alon, the patch is to the ebuild. Are you saying that upstream maintains > the ebuild? sorry, applied. please understand that the bugs database is not scratch pad, especially for niche issues like cross-compile, please provide a focused description of downstream issues. you already opened too many upstream specific issues that it is very hard to keep track after the relevant fixes.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fbed82e27825480ab0c3b75d18042e9829bb359f commit fbed82e27825480ab0c3b75d18042e9829bb359f Author: Alon Bar-Lev <alonbl@gentoo.org> AuthorDate: 2018-04-27 16:50:16 +0000 Commit: Alon Bar-Lev <alonbl@gentoo.org> CommitDate: 2018-04-27 16:50:16 +0000 dev-libs/libgcrypt: fix cross compile with libgpg-error Closes: https://bugs.gentoo.org/show_bug.cgi?id=653930 Thanks-To: Joe Harvell dev-libs/libgcrypt/libgcrypt-1.8.2-r2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
(In reply to Alon Bar-Lev from comment #24) > (In reply to Joe Harvell from comment #23) > > Alon, the patch is to the ebuild. Are you saying that upstream maintains > > the ebuild? > > sorry, applied. > please understand that the bugs database is not scratch pad, especially for > niche issues like cross-compile, please provide a focused description of > downstream issues. > you already opened too many upstream specific issues that it is very hard to > keep track after the relevant fixes. Thanks for the fix. Just to clarify. If I find a bug in the future that I know to be only upstream, do you want a Gentoo bug report to track it or not? I understand you also want a better summary.
(In reply to Joe Harvell from comment #26) > (In reply to Alon Bar-Lev from comment #24) > > (In reply to Joe Harvell from comment #23) > > > Alon, the patch is to the ebuild. Are you saying that upstream maintains > > > the ebuild? > > > > sorry, applied. > > please understand that the bugs database is not scratch pad, especially for > > niche issues like cross-compile, please provide a focused description of > > downstream issues. > > you already opened too many upstream specific issues that it is very hard to > > keep track after the relevant fixes. > > Thanks for the fix. > > Just to clarify. If I find a bug in the future that I know to be only > upstream, do you want a Gentoo bug report to track it or not? > > I understand you also want a better summary. It depends a bit on the context. Having a bug downstream makes it easier to locate the upstream bug, so in particular if an issue might stay open for a while, it is nice to have a collection of workarounds and patches downstream that users can apply. If only filing one bug, it should be upstream as that is where the fix should ultimately land. We try to avoid carrying downstream patches that aren't very specific to Gentoo, in particular for security related packages (although build issues are likely easier to accept than a change in rng etc..)
