Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 560134 - dev-libs/libgpg-error fails to cross-compile for ARM
Summary: dev-libs/libgpg-error fails to cross-compile for ARM
Status: RESOLVED DUPLICATE of bug 526146
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: ARM Linux
: Normal major (vote)
Assignee: Crypto team [DISABLED]
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-10 14:12 UTC by Vince C.
Modified: 2015-09-12 11:08 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
dev-libs/libgpg-error-1.13 build log (dev-libs:libgpg-error-1.13:20150910-134341.log,13.00 KB, text/plain)
2015-09-10 14:19 UTC, Vince C.
Details
dev-libs/libgpg-error-1.13 environment info (environment,102.98 KB, text/plain)
2015-09-10 14:21 UTC, Vince C.
Details
dev-libs/libgpg-error-1.18 build log (dev-libs:libgpg-error-1.18:20150910-134651.log,16.52 KB, text/plain)
2015-09-10 14:24 UTC, Vince C.
Details
dev-libs/libgpg-error-1.18 environment info (environment,103.03 KB, text/plain)
2015-09-10 14:25 UTC, Vince C.
Details
Ebuild patch for dev-libs/libgpg-error-1.18 (libgpg-error-1.18.ebuild.patch,623 bytes, patch)
2015-09-10 16:47 UTC, Vince C.
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vince C. 2015-09-10 14:12:41 UTC
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
Comment 1 Vince C. 2015-09-10 14:19:16 UTC
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
Comment 2 Vince C. 2015-09-10 14:21:14 UTC
Created attachment 411542 [details]
dev-libs/libgpg-error-1.13 environment info
Comment 3 Vince C. 2015-09-10 14:24:52 UTC
Created attachment 411544 [details]
dev-libs/libgpg-error-1.18 build log
Comment 4 Vince C. 2015-09-10 14:25:37 UTC
Created attachment 411546 [details]
dev-libs/libgpg-error-1.18 environment info
Comment 5 Vince C. 2015-09-10 14:28:14 UTC
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.
Comment 6 Vince C. 2015-09-10 16:47:26 UTC
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...
Comment 7 Vince C. 2015-09-10 16:50:51 UTC
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."
Comment 8 Vince C. 2015-09-10 17:18:30 UTC
Trolling apart, I find Debian naming conventions, unlike Gentoo in this very case, to be a wee bit messy.
Comment 9 SpanKY gentoo-dev 2015-09-11 18:56:51 UTC
there's no need to use "crossdev" in the summary.  you're simply cross-compiling, and crossdev is largely irrelevant at this point.
Comment 10 Alon Bar-Lev (RETIRED) gentoo-dev 2015-09-11 19:00:21 UTC

*** This bug has been marked as a duplicate of bug 526146 ***
Comment 11 Vince C. 2015-09-12 10:12:08 UTC
(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.
Comment 12 Alon Bar-Lev (RETIRED) gentoo-dev 2015-09-12 10:14:43 UTC
(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.
Comment 13 Vince C. 2015-09-12 11:08:45 UTC
(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.