app-crypt/gpgme uses script called gpgrt-config from dev-libs/libgpg-error instead of pkg-config that would give correct paths. It merely parses provided libassuan.pc to get cflags, libs paths. The quick solution is to provide PKG_CONFIG_SYSROOT_DIR in ebuild file. If this solution is acceptable i'll fire a patch for all current gpgpme ebuilds. Reproducible: Always
1. Isn’t that normally set by crossdev in make.conf? 2. It’s not clear how the current way is wrong (even though I agree it’s not ideal to reinvent pkgconfig). It’d be useful if you could attach logs showing the problem
Created attachment 737971 [details, diff] 0001-app-crypt-gpgme-1.16-crossdev-export-PKG_CONFIG_SYSR
(In reply to Sam James from comment #1) > 1. Isn’t that normally set by crossdev in make.conf? > > 2. It’s not clear how the current way is wrong (even though I agree it’s not > ideal to reinvent pkgconfig). It’d be useful if you could attach logs > showing the problem sry, 5 sec - you have responded too fast :), still attaching.
Created attachment 737974 [details] Failed crossdev app-crypt/gpgme merge log
Created attachment 737977 [details] emerge.info
(In reply to Sam James from comment #1) > 1. Isn’t that normally set by crossdev in make.conf? > > 2. It’s not clear how the current way is wrong (even though I agree it’s not > ideal to reinvent pkgconfig). It’d be useful if you could attach logs > showing the problem 1. PKG_CONFIG_SYSROOT_DIR is set in crossdev pkg-config config wrapper. The reason is this particle package doesn't use pkg-config, in our case riscv64-unknown-linux-gnu-pkg-config, it's not possible to simply replace /usr/bin/gpgrt-config with pkg-config as it uses arguments not compatible with pkg-config, i.e. "GPG_ERROR_CONFIG='/usr/bin/gpgrt-config --libdir=/usr/riscv64-unknown-linux-gnu/usr/lib64/lp64d gpg-error'". 2. From my point of view parsing *.pc files to strip paths from them is really not a correct way to get required paths, we could simply relay on pkg-config crosswrapper. But the mechanism in m4/libassuan.m4 (part of gpgme) uses gpgrt-config for paths detection.
Simply setting PKG_CONFIG_SYSROOT_DIR="${ROOT}" worked for me, however it is not set by default, i think it can be closed.
Setting PKG_CONFIG_SYSROOT_DIR="${ROOT}" in ${SYSROOT}/etc/portage/make.conf solves the problem.
(In reply to Nikita Shubin from comment #6) > (In reply to Sam James from comment #1) > > 1. Isn’t that normally set by crossdev in make.conf? > > > > 2. It’s not clear how the current way is wrong (even though I agree it’s not > > ideal to reinvent pkgconfig). It’d be useful if you could attach logs > > showing the problem > > 1. PKG_CONFIG_SYSROOT_DIR is set in crossdev pkg-config config wrapper. > > The reason is this particle package doesn't use pkg-config, in our case > riscv64-unknown-linux-gnu-pkg-config, it's not possible to simply replace > /usr/bin/gpgrt-config with pkg-config as it uses arguments not compatible > with pkg-config, i.e. "GPG_ERROR_CONFIG='/usr/bin/gpgrt-config > --libdir=/usr/riscv64-unknown-linux-gnu/usr/lib64/lp64d gpg-error'". > > 2. From my point of view parsing *.pc files to strip paths from them is > really not a correct way to get required paths, we could simply relay on > pkg-config crosswrapper. But the mechanism in m4/libassuan.m4 (part of > gpgme) uses gpgrt-config for paths detection. You are right about this, but we can't change Werner Koch's mind right now. I wish we could. Could you please try setting something like: GPG_ERROR_CONFIG="${BROOT}/usr/bin/${CHOST}-gpg-error-config" LIBASSUAN_CONFIG="${BROOT}/usr/bin/libassuan-config" like in gnupg*.ebuild? The same techniques should work for the whole gnupg suite given the same macros and the same author(s). (In reply to Nikita Shubin from comment #7) > Simply setting PKG_CONFIG_SYSROOT_DIR="${ROOT}" worked for me, however it is > not set by default, i think it can be closed. PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/" was set by default with crossdev for me, fwiw. I seemed to be able to start compiling without setting those variables I mentioned as arguments to econf (configure): >checking for gpg-error-config... /usr/bin/gpg-error-config >checking for gpgrt-config... /usr/bin/gpgrt-config >configure: Use gpgrt-config with /usr/aarch64-gentoo-linux-musl/usr/lib as gpg-error-config >checking for GPG Error - version >= 1.36... yes (1.42-unknown) >configure: Use gpgrt-config as libassuan-config >checking for LIBASSUAN - version >= 2.4.2... yes (2.5.5) >checking LIBASSUAN API version... okay Then it bailed for other reasons, and setting the things I suggested in the ebuild failed. So, I think this did work for you, but I think there is still a bug here, right? We shouldn't need to add this additional thing to make.conf.
So, your patch works for me (which makes sense!), I'm just not understanding why gpg is different. That is, I'm surprised nobody else has hit this before doing "normal cross" (SYSROOT == ROOT). Any ideas why?
(In reply to Sam James from comment #10) > So, your patch works for me (which makes sense!), I'm just not understanding > why gpg is different. > > That is, I'm surprised nobody else has hit this before doing "normal cross" > (SYSROOT == ROOT). Any ideas why? as in, I don't get why nobody else has tried and failed to compile gpgme, and I'm wondering if there's a "wk-compliant" way to coax his tools into doing what we want without setting this variable.
(In reply to Sam James from comment #11) > (In reply to Sam James from comment #10) > > So, your patch works for me (which makes sense!), I'm just not understanding > > why gpg is different. > > > > That is, I'm surprised nobody else has hit this before doing "normal cross" > > (SYSROOT == ROOT). Any ideas why? > > as in, I don't get why nobody else has tried and failed to compile gpgme, > and I'm wondering if there's a "wk-compliant" way to coax his tools into > doing what we want without setting this variable. dm0 seems to do [0] what you ruled out before (replacing it with a forced pkg-config call): > echo 'LIBASSUAN_CONFIG="/usr/bin/$CHOST-pkg-config libassuan"' >> "$portage/env/cross-libassuan.conf" [0] https://github.com/dm0-/installer/blob/c0df309e38715273921c3ddb3b76219e9cc81928/gentoo.sh#L267
Hello Sam, On my different Gentoo machine riscv64-unknown-linux-gnu-emerge gpgme emerged succesfully despite i commented out #PKG_CONFIG_SYSROOT_DIR, i ll try to reproduce on same machine that had it. I noticed a bad thing i was doing i have /bin/bash'ed on failed machine instead of /bin/login.
Okay i nailed it to: working: libtool: compile: riscv64-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../conf -O2 -pipe -fomit-frame-pointer -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k -Wno-missing-field-initializers -Wno-sign-compare -Wno-format-zero-length -Wno-format-truncation -Wno-sizeof-pointer-div -c op-support.c -fPIC -DPIC -o .libs/op-support.o not working: libtool: compile: riscv64-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../conf -I/usr/include -O2 -pipe -fomit-frame -pointer -mcpu=sifive-u74 -mtune=sifive-7-series -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wno-format-y2k -Wn o-missing-field-initializers -Wno-sign-compare -Wno-format-zero-length -Wno-format-truncation -Wno-sizeof-pointer-div -c op-support.c -fPIC -DPIC -o .libs/op-support.o The difference is -I/usr/include. But still i have no idea why they are working different and why first machine was **fixed**.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=313127751b219670d3c256a9c50dbf3ed6fca900 commit 313127751b219670d3c256a9c50dbf3ed6fca900 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-03-07 04:26:24 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-03-07 04:26:24 +0000 app-crypt/gpgme: fix cross-compile (finding libassuan) Closes: https://bugs.gentoo.org/811933 Thanks-to: m (#gentoo-riscv) Signed-off-by: Sam James <sam@gentoo.org> app-crypt/gpgme/gpgme-1.17.1.ebuild | 2 ++ 1 file changed, 2 insertions(+)
*** Bug 835751 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b140713e716f7ba9927dbfac65714f2bfec63a9a commit b140713e716f7ba9927dbfac65714f2bfec63a9a Author: orbea <orbea@riseup.net> AuthorDate: 2022-08-31 01:00:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-01 02:15:48 +0000 app-crypt/gpgme: Remove --with-libassuan-prefix The --with-libassuan-prefix configure argument causes app-crypt/gpgme to use the deprecated libassuan-config script instead of the maintained gpgrt-config script. Bug: https://bugs.gentoo.org/811933 Closes: https://bugs.gentoo.org/844226 Upstream-Bug: https://dev.gnupg.org/T6136 Signed-off-by: Sam James <sam@gentoo.org> app-crypt/gpgme/gpgme-1.18.0-r1.ebuild | 130 +++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d920faef3dd6d61ff4163c523a1ec0413c98a790 commit d920faef3dd6d61ff4163c523a1ec0413c98a790 Author: orbea <orbea@riseup.net> AuthorDate: 2022-08-31 00:57:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-01 02:15:41 +0000 dev-libs/libgpg-error: Add gpgrt-config patch Adds a patch to remove the standard system --libdir from the gpgrt-config output. This is required when building app-crypt/gpgme with slibtool to avoid linking with the old system library instead of the newly built library. Bug: https://bugs.gentoo.org/811933 Bug: https://bugs.gentoo.org/844226 Upstream-Bug: https://dev.gnupg.org/T6136 Upstream-Commit: https://dev.gnupg.org/rE4615816f71e91f4c3bb8b0e4122dd153ec7c1927 Signed-off-by: Sam James <sam@gentoo.org> .../libgpg-error-1.45-gpgrt_config_libdir.patch | 56 ++++++++++++++++++ dev-libs/libgpg-error/libgpg-error-1.45-r1.ebuild | 68 ++++++++++++++++++++++ 2 files changed, 124 insertions(+)
