Bug 653912 – 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

• Status: RESOLVED DUPLICATE of bug 584052
• Product: Gentoo Linux

[Description Joe Harvell 2018-04-23 17:39:05 UTC]

Created attachment 528292 [details]
output of sudo armv7a-pip-linux-gnueabi-emerge --info

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:

/usr/armv7a-pip-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.29/work/libgpg-error-1.29/src/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
make[2]: *** [Makefile:1464: gpg-error.h] Error 1
make[2]: Leaving directory '/usr/armv7a-pip-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.29/work/libgpg-error-1.29-.arm/src'

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/libgpg-error-1.29

Actual Results:  
dev-libs/libgpg-error-1.29 compile fails

Expected Results:  
dev-libs/libgpg-error-1.29 succeeds

I have successfully installed 110 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

[Comment 1 Joe Harvell 2018-04-23 17:39:25 UTC]

Created attachment 528294 [details]
output of sudo emerge --info

[Comment 2 Joe Harvell 2018-04-23 17:41:16 UTC]

Created attachment 528296 [details]
build.log

[Comment 3 Joe Harvell 2018-04-23 17:41:56 UTC]

Created attachment 528298 [details]
eclass-debug.log

[Comment 4 Joe Harvell 2018-04-23 17:42:58 UTC]

Created attachment 528300 [details]
environment

[Comment 5 Joe Harvell 2018-04-23 17:43:28 UTC]

Created attachment 528302 [details]
config.log

[Comment 6 Joe Harvell 2018-04-23 17:43:46 UTC]

Created attachment 528304 [details]
configure

[Comment 7 Alon Bar-Lev (RETIRED) 2018-04-23 18:58:15 UTC]

dup of bug#584052?

[Comment 8 Joe Harvell 2018-04-23 22:27:10 UTC]

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.

[Comment 9 Joe Harvell 2018-04-23 22:55:16 UTC]

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

[Comment 10 Joe Harvell 2018-04-24 00:46:25 UTC]

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?

[Comment 11 Joe Harvell 2018-04-24 02:10:42 UTC]

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

[Comment 12 Alon Bar-Lev (RETIRED) 2018-04-24 05:04:54 UTC]

Please either use upstream supported libgpg-error toolchain or patch the package.

*** This bug has been marked as a duplicate of bug 584052 ***

[Comment 13 Joe Harvell 2018-04-24 05:11:02 UTC]

(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.

[Comment 14 Alon Bar-Lev (RETIRED) 2018-04-24 05:22:29 UTC]

(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