Package dev-libs/libgpg-error comes as a dependency of dev-libs/libgcrypt. When cross-compiling on a X86_64 host for the armv7a-hardfloat-linux-gnueabi target, the compile phase expects a (non-existent) file src/syscfg/lock-obj-pub.linux-gnueabi.h although it should find the matching lock-obj-pub.arm-unknown-linux-gnueabihf.h instead. Reproducible: Always Steps to Reproduce: armv7a-hardfloat-linux-gnueabi-emerge libgpg-error
Created attachment 411534 [details] dev-libs/libgpg-error-1.13 build log I have tried versions 1.13, 1.18 and 1.19. All fail with the same error: /portage/tmp/portage/dev-libs/libgpg-error-1.13/work/libgpg-error-1.13/src/gpg-error.h.in:289: error including `/portage/tmp/portage/dev-libs/libgpg-error-1.13/work/libgpg-error-1.13/src/syscfg/lock-obj-pub.linux-gnueabi.h': No such file or directory
Created attachment 411542 [details] dev-libs/libgpg-error-1.13 environment info
Created attachment 411544 [details] dev-libs/libgpg-error-1.18 build log
Created attachment 411546 [details] dev-libs/libgpg-error-1.18 environment info
It looks like ARM is only supported from version 1.18 and onwards: # ll /portage/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/syscfg/ total 112 -rw-r--r-- 1 portage portage 554 18 sep 2014 lock-obj-pub.aarch64-apple-darwin.h -rw-r--r-- 1 portage portage 676 27 jui 2014 lock-obj-pub.aarch64-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 619 27 jui 2014 lock-obj-pub.alpha-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 504 18 sep 2014 lock-obj-pub.arm-apple-darwin.h -rw-r--r-- 1 portage portage 396 29 jan 2014 lock-obj-pub.arm-unknown-linux-androideabi.h -rw-r--r-- 1 portage portage 511 27 jui 2014 lock-obj-pub.arm-unknown-linux-gnueabi.h -rw-r--r-- 1 portage portage 513 27 jui 2014 lock-obj-pub.arm-unknown-linux-gnueabihf.h -rw-r--r-- 1 portage portage 724 5 aoû 2014 lock-obj-pub.hppa-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 552 27 jui 2014 lock-obj-pub.i486-pc-gnu.h -rw-r--r-- 1 portage portage 506 27 jui 2014 lock-obj-pub.i486-pc-kfreebsd-gnu.h -rw-r--r-- 1 portage portage 503 27 jui 2014 lock-obj-pub.i486-pc-linux-gnu.h -rw-r--r-- 1 portage portage 503 23 oct 2014 lock-obj-pub.i586-pc-linux-gnu.h -rw-r--r-- 1 portage portage 508 27 jui 2014 lock-obj-pub.m68k-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 1466 11 sep 2014 lock-obj-pub.mingw32.h -rw-r--r-- 1 portage portage 627 25 oct 2014 lock-obj-pub.mips64el-unknown-linux-gnuabi64.h -rw-r--r-- 1 portage portage 510 27 jui 2014 lock-obj-pub.mipsel-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 508 27 jui 2014 lock-obj-pub.mips-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 563 23 oct 2014 lock-obj-pub.or1k-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 625 29 sep 2014 lock-obj-pub.powerpc64le-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 623 27 jui 2014 lock-obj-pub.powerpc64-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 511 27 jui 2014 lock-obj-pub.powerpc-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 615 27 jui 2014 lock-obj-pub.s390x-ibm-linux-gnu.h -rw-r--r-- 1 portage portage 507 27 jui 2014 lock-obj-pub.sh4-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 621 23 sep 2014 lock-obj-pub.sparc64-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 509 27 jui 2014 lock-obj-pub.sparc-unknown-linux-gnu.h -rw-r--r-- 1 portage portage 618 27 jui 2014 lock-obj-pub.x86_64-pc-kfreebsd-gnu.h -rw-r--r-- 1 portage portage 615 27 jui 2014 lock-obj-pub.x86_64-pc-linux-gnu.h -rw-r--r-- 1 portage portage 563 27 jui 2014 lock-obj-pub.x86_64-pc-linux-gnux32.h # ll /portage/tmp/portage/dev-libs/libgpg-error-1.13/work/libgpg-error-1.13/src/syscfg/ total 8 -rw-r--r-- 1 portage portage 396 29 jan 2014 lock-obj-pub.arm-unknown-linux-androideabi.h -rw-r--r-- 1 portage portage 1457 15 jan 2014 lock-obj-pub.mingw32.h Consequently dev-libs/libgpg-error-1.18 (and later) accordingly needs some fixing.
Created attachment 411556 [details, diff] Ebuild patch for dev-libs/libgpg-error-1.18 It turns out there is a binary that creates a header file, src/syscfg/lock-obj-pub.*.h depending on the target platform. The include files in the latter directory represent Debian-like triplet names. I created symbolic links for the ARM platform, namely lock-obj-pub.armv7a-softfloat-linux-gnueabi.h and lock-obj-pub.armv7a-hardfloat-linux-gnueabi.h. But there are other platforms to represent, of which I have no idea (yet) how Gentoo names them so I left a TODO comment in the ebuild. If any maintainer feels like filling the gap...
Wrong explanation. Let me rephrase. The correct information is: "It turns out there is a binary, "src/mkheader", that creates a header file by including one of src/syscfg/lock-obj-pub.*.h depending on the target platform."
Trolling apart, I find Debian naming conventions, unlike Gentoo in this very case, to be a wee bit messy.
there's no need to use "crossdev" in the summary. you're simply cross-compiling, and crossdev is largely irrelevant at this point.
*** This bug has been marked as a duplicate of bug 526146 ***
(In reply to SpanKY from comment #9) > there's no need to use "crossdev" in the summary. you're simply > cross-compiling, and crossdev is largely irrelevant at this point. I don't agree. The error is due to the project (obviously) targeting Debian for cross-compiling, just see the header file name lock-obj-pub.arm-unknown-linux-gnueabihf.h for ARM hard float. The issue is raised because crossdev, on Gentoo, uses other naming conventions for triplets hence cross-compiling on Gentoo fails while it succeeds on Debian. Just look at the code that calls mkheader. Conclusion: it *is* specific to Crossdev.
(In reply to Vince C. from comment #11) > (In reply to SpanKY from comment #9) > > there's no need to use "crossdev" in the summary. you're simply > > cross-compiling, and crossdev is largely irrelevant at this point. > > I don't agree. The error is due to the project (obviously) targeting Debian > for cross-compiling, just see the header file name > lock-obj-pub.arm-unknown-linux-gnueabihf.h for ARM hard float. The issue is > raised because crossdev, on Gentoo, uses other naming conventions for > triplets hence cross-compiling on Gentoo fails while it succeeds on Debian. > Just look at the code that calls mkheader. > > Conclusion: it *is* specific to Crossdev. you can use any triple you like with crossdev, it is one of the most (if not most) flexible solution any distro provides. hardfloat is default, you do not need to specify it in the 2nd component, even if you do you should use unknown_hardfloat.
(In reply to Alon Bar-Lev from comment #12) Sorry I don't understand the relation between this: > you can use any triple you like with crossdev, it is one of the most (if not > most) flexible solution any distro provides. > > hardfloat is default, you do not need to specify it in the 2nd component, > even if you do you should use unknown_hardfloat. this: > there's no need to use "crossdev" in the summary. and this: > I don't agree. The error is due to the project (obviously) targeting Debian > for cross-compiling, just see the header file name > lock-obj-pub.arm-unknown-linux-gnueabihf.h for ARM hard float. The issue is > raised because crossdev, on Gentoo, uses other naming conventions for > triplets hence cross-compiling on Gentoo fails while it succeeds on Debian. > Just look at the code that calls mkheader. > > Conclusion: it *is* specific to Crossdev.
