Summary: | dev-libs/libgpg-error-1.29: cross compile fail: gpg-error.h.in:491: error including `/usr/armv7a-pip-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.29/work/libgpg-error-1.29/src/syscfg/lock-obj-pub.linux-gnueabi.h': No such file or directory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joe Harvell <landshark> |
Component: | Current packages | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | alonbl, jstein |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
output of sudo armv7a-pip-linux-gnueabi-emerge --info
output of sudo emerge --info build.log eclass-debug.log environment config.log configure |
Description
Joe Harvell
2018-04-23 17:39:05 UTC
Created attachment 528294 [details]
output of sudo emerge --info
Created attachment 528296 [details]
build.log
Created attachment 528298 [details]
eclass-debug.log
Created attachment 528300 [details]
environment
Created attachment 528302 [details]
config.log
Created attachment 528304 [details]
configure
dup of bug#584052? It is the same problem described in https://bugs.gentoo.org/584052. I looked at upstream's src/mkheader.c:canon_host_triplet and see that it has mappings for the following: {"arm-unknown-linux-gnueabihf", "arm-unknown-linux-gnueabi" }, {"armv7-unknown-linux-gnueabihf" }, {"armv5-unknown-linux-musleabi" }, {"armv6-unknown-linux-musleabihf" }, Sounds like upstream wants an exact match for the first component armv7a in my case, and there is no mapping. Does the ebuild translate my value of "armv7a-pip-linux-gnueabi" into "armv7a-unknown-linux-gnueabi"? In that case I can create a brand new cross toolchain as "armv7-pip-linux-gnueabi" so that I can build libgpg. I have a reason I need to use the special value "pip" in the vendor field. By the way, I understand the reasoning for being stubborn and not making changes to support upstream in this case. But it would be nice if crossdev had some kind of comment/warning about this. From what I can see, anyone who uses crossdev to build for ARM Cortex A8 is going to use armv7a-* for their cross toolchain. and libgpg is not an esoteric package. It is part of @system for the basic ARM profile. So I have to be able to successfully build that package to make an ARM system. Apparently crossdev can't successfully build a toolchain for target armv7-pip-linux-gnueabihf. The stage1 compiler fails to build glibc with some error about supported opcodes. Seems like armv7a is a must here, so I am forced to make my own ebuild patch while in the background I try to push some 'armv7a-unknown-*' mappings upstream. ../sysdeps/arm/sysdep.h: Assembler messages: ../sysdeps/arm/sysdep.h:144: Error: selected processor does not support ARM opcodes ../sysdeps/arm/crtn.S:48: Error: attempt to use an ARM instruction on a Thumb-only processor -- `pop {r3,pc}' ../sysdeps/arm/crtn.S:56: Error: attempt to use an ARM instruction on a Thumb-only processor -- `pop {r3,pc}' make[2]: *** [/mnt/striped_2/portage-tmp/portage/cross-armv7-pip-linux-gnueabihf/glibc-2.26-r6/work/build-default-armv7-pip-linux-gnueabihf-nptl/sysd-rules:381: /mnt/striped_2/portage-tmp/portage/cross-armv7-pip-linux-gnueabihf/glibc-2.26-r6/work/build-default-armv7-pip-linux-gnueabihf-nptl/csu/crtn.o] Error 1 make[2]: *** Waiting for unfinished jobs.... ../sysdeps/arm/sysdep.h: Assembler messages: ../sysdeps/arm/sysdep.h:144: Error: selected processor does not support ARM opcodes ../sysdeps/arm/crti.S:64: Error: attempt to use an ARM instruction on a Thumb-only processor -- `ldr r3,.LGOT' ../sysdeps/arm/crti.S:65: Error: attempt to use an ARM instruction on a Thumb-only processor -- `ldr r2,.LGOT+4' ../sysdeps/arm/crti.S:67: Error: attempt to use an ARM instruction on a Thumb-only processor -- `add r3,pc,r3' ../sysdeps/arm/crti.S:68: Error: attempt to use an ARM instruction on a Thumb-only processor -- `ldr r2,[r3,r2]' ../sysdeps/arm/crti.S:69: Error: attempt to use an ARM instruction on a Thumb-only processor -- `cmp r2,#0' ../sysdeps/arm/crti.S:70: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bxeq lr' ../sysdeps/arm/crti.S:71: Error: attempt to use an ARM instruction on a Thumb-only processor -- `b __gmon_start__' ../sysdeps/arm/crti.S:83: Error: attempt to use an ARM instruction on a Thumb-only processor -- `push {r3,lr}' ../sysdeps/arm/crti.S:85: Error: attempt to use an ARM instruction on a Thumb-only processor -- `bl call_weak_fn' ../sysdeps/arm/crti.S:95: Error: attempt to use an ARM instruction on a Thumb-only processor -- `push {r3,lr}' make[2]: *** [/mnt/striped_2/portage-tmp/portage/cross-armv7-pip-linux-gnueabihf/glibc-2.26-r6/work/build-default-armv7-pip-linux-gnueabihf-nptl/sysd-rules:381: /mnt/striped_2/portage-tmp/portage/cross-armv7-pip-linux-gnueabihf/glibc-2.26-r6/work/build-default-armv7-pip-linux-gnueabihf-nptl/csu/crti.o] Error 1 I did some more digging on this, especially https://bugs.gnupg.org/gnupg/issue2370, which is the fix that Peter Levine submitted upstream (rejected). I was mistaken in https://bugs.gentoo.org/653912#c8 about config.sub converting "armv7a-pip-linux-gnueabi" to "armv7a-unknown-linux-gnueabi". It does not. By the way, the reason I am using "pip" as the vendor/manufacturer of the GNU "triplet" has to do with how crossdev works on Gentoo. It's complicated to explain why, but if you intend to build a full system with the cross toolchain, you end up having to build it in the crossdev root "/usr/<target>" directory on the host. So I use a custom vendor/manufacturer name "pip" to distinguish this toolchain from another copy on the same host to build for the same target but not the same contents. So there are two problems here related to libgpg-error: 1) As described in https://bugs.gentoo.org/653912#c9, I can't produce a toolchain with the latest versions of binutils, linux-headers, glibc and gcc using "arm" as the first component of target. Apparently I need to use "arm7a" for this target. But upstream libgpg-error has no mapping for armv7a-* to header file. I think the right way to address this is to push that change upstream. 2) Upstream libgpg seems unwilling to accept arbitrary values for the vendor/manufacturer component of target on the basis that they think different values here may represent different ABIs and therefore require a new lock structure. For #2, it seems both upstream and Gentoo are unwilling to make a change. So it looks like I am going to have to maintain Peter Levine's patch in my own overlay in perpetuity. Another option would be to not use the libgpg-error package at all. Is there an alternative? Why is it needed in @system? I succesfully installed this using the the patch consisting of attachments https://bugs.gentoo.org/attachment.cgi?id=443990 and https://bugs.gentoo.org/attachment.cgi?id=436842 Please either use upstream supported libgpg-error toolchain or patch the package. *** This bug has been marked as a duplicate of bug 584052 *** (In reply to Alon Bar-Lev from comment #12) > Please either use upstream supported libgpg-error toolchain or patch the > package. > > *** This bug has been marked as a duplicate of bug 584052 *** I assume by "patch the package" you mean use my own private patch, which I have. You don't mean submit a patch to Gentoo right? Because it would just be the one you already rejected from 584052. (In reply to Joe Harvell from comment #13) > (In reply to Alon Bar-Lev from comment #12) > > Please either use upstream supported libgpg-error toolchain or patch the > > package. > > > > *** This bug has been marked as a duplicate of bug 584052 *** > > I assume by "patch the package" you mean use my own private patch, which I > have. You don't mean submit a patch to Gentoo right? Because it would just > be the one you already rejected from 584052. Correct. You should be able to put your specific patch which is a symlink to the supported toolchain in /etc/portage/patches[1] [1] https://wiki.gentoo.org/wiki//etc/portage/patches |