Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 526146 - dev-libs/libgpg-error-1.15 ignores CC when cross-compiling
Summary: dev-libs/libgpg-error-1.15 ignores CC when cross-compiling
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Crypto team [DISABLED]
: 560134 (view as bug list)
Depends on:
Reported: 2014-10-20 20:43 UTC by gentoo-bugs
Modified: 2015-09-12 16:57 UTC (History)
2 users (show)

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

build.log (build.log,16.08 KB, text/plain)
2014-10-20 20:45 UTC, gentoo-bugs

Note You need to log in before you can comment on or make changes to this bug.
Description gentoo-bugs 2014-10-20 20:43:38 UTC
I am trying to emerge libgpg-error-1.15, inside a cross-dev environment. I get the following error while emerging:

cc -g -O0 -I. -I/usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15/src -o mkheader /usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15/src/mkheader.c
rm lock-obj-pub.native.h 2>/dev/null
Makefile:1211: recipe for target 'gpg-error.h' failed
make[2]: [gpg-error.h] Error 1 (ignored)
./mkheader linux-gnueabi armv6j-hardfloat-linux-gnueabi  /usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15/src/ \
                   ../config.h 1.15 0x010f00 >gpg-error.h
/usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15/src/ error including `/usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15/src/syscfg/lock-obj-pub.linux-gnueabi.h': No such file or directory
Makefile:1211: recipe for target 'gpg-error.h' failed
make[2]: *** [gpg-error.h] Error 1
make[2]: Leaving directory '/usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15-.arm/src'
Makefile:402: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15-.arm'
Makefile:333: recipe for target 'all' failed
make: *** [all] Error 2

Reproducible: Always

Steps to Reproduce:
1. Set up cross-dev environment: crossdev -S -v -t armv6j-hardfloat-linux-gnueabi
2. emerge libgpg-error

Portage 2.2.8-r2 (default/linux/arm/13.0/armv6j, gcc-4.7.3, unavailable, 3.16.6 x86_64)
                         System Settings
System uname: Linux-3.16.6-x86_64-Intel-R-_Core-TM-_i7-4700MQ_CPU_@_2.40GHz-with-gentoo-2.2
KiB Mem:     8089876 total,   4718060 free
KiB Swap:          0 total,         0 free
Timestamp of tree: Mon, 20 Oct 2014 00:45:01 +0000
ld GNU ld (Gentoo 2.23.2 p1.0) 2.23.2
sys-apps/baselayout: 2.2
Repositories: gentoo
CFLAGS="-O2 -pipe -fomit-frame-pointer"
CONFIG_PROTECT="/etc /usr/share/easy-rsa /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -fomit-frame-pointer"
FCFLAGS="-O2 -pipe -march=armv6j"
FEATURES="assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news nodoc noinfo noman parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -pipe -march=armv6j"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
USE="acl arm berkdb bzip2 cli cracklib crypt cxx dri fortran gdbm iconv ipv6 modules ncurses nls nptl openmp pcre readline session ssl tcpd unicode zlib" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="exynos fbdev omap omapfb dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

The cross-compilation environment for the Raspberry pi has been set up as described in this wiki article:

PORTAGE_CONFIGROOT="/usr/armv6j-hardfloat-linux-gnueabi"  emerge -pqv '=dev-libs/libgpg-error-1.15::gentoo'
[ebuild  N    ] dev-libs/libgpg-error-1.15 to /usr/armv6j-hardfloat-linux-gnueabi/ USE="nls -common-lisp -static-libs" 

 * IMPORTANT: 3 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

Essentially, crossdev environment created with this command: crossdev -S -v -t armv6j-hardfloat-linux-gnueabi

Emerging with this command:
PORTAGE_CONFIGROOT="/usr/armv6j-hardfloat-linux-gnueabi" emerge -av libgpg-error
Comment 1 gentoo-bugs 2014-10-20 20:45:23 UTC
Created attachment 387086 [details]
Comment 2 Alon Bar-Lev (RETIRED) gentoo-dev 2014-10-20 21:49:18 UTC
CC=/bin/false ebuild libgpg-error-1.15.ebuild clean install

uses /bin/false

Please attach config.log from:

Comment 3 Alon Bar-Lev (RETIRED) gentoo-dev 2014-10-20 21:56:42 UTC
use of cc in this case is intentional as this program should work on build machine.
Comment 4 Alon Bar-Lev (RETIRED) gentoo-dev 2014-10-20 22:05:17 UTC
Error is:

/usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15/src/ error including `/usr/armv6j-hardfloat-linux-gnueabi/tmp/portage/dev-libs/libgpg-error-1.15/work/libgpg-error-1.15/src/syscfg/lock-obj-pub.linux-gnueabi.h': No such file or directory
Comment 5 Alon Bar-Lev (RETIRED) gentoo-dev 2014-10-20 22:07:17 UTC

Libgpg-error needs to figure out some platform specific properties.
These are used to build the platform specific gpg-error.h file.  The
detection is done during build time but can't be done when
cross-compiling.  Thus if you run into an error during building you
need to figure out these values.  You may use these commands:

  ./configure --prefix=TARGETDIR --host=TARGET --build=$build
  cd src
  make gen-posix-lock-obj
  scp gen-posix-lock-obj TARGET:
  ssh TARGET ./gen-posix-lock-obj >tmp.h
  mv tmp.h "syscfg/$(awk 'NR==1 {print $2}' tmp.h)"

If you are using a VPATH build adjust accordingly.  If this all works
for you (make sure to run the test programs on the target platform),
please send the generated file to the gnupg-devel mailing list so that
we can include it in the next release.

I guess your problem is that the TARGET is not pre-built at src/syscfg.

Nothing we can actually do if the above is the sequence.
Comment 6 Alon Bar-Lev (RETIRED) gentoo-dev 2014-10-20 22:30:06 UTC
Please also try to use armv6j-unknown-linux-gnueabi instead of armv6j-hardfloat-linux-gnueabi, it will use hardware float control anyway and probably will work. Also note that the notation of armv6j-unknown_hardfloat-linux-gnueabi is better.
Comment 7 Alon Bar-Lev (RETIRED) gentoo-dev 2015-09-11 19:00:21 UTC
*** Bug 560134 has been marked as a duplicate of this bug. ***
Comment 8 Vince C. 2015-09-12 10:41:45 UTC

This bug has been around for about one year and NO solution has been implemented. I took it up for a couple of hours and I came up with a fix that might be temporary but still I could at least cross-compile. Look, I've read about doing the mapping between platforms in canon_host_triplet but here are my facts:

- this code targets Linux
- I've created symbolic links for the mapping and it *just works* with crossdev
- won't induce regressions since it's a basic file-based mapping
- mapping with symbolic links is the most straightforward way, no change in makefiles, source files, nothing.

Obviously lock-obj-pub.arm-unknown-linux-gnueabihf.h and lock-obj-pub.armv7a-hardfloat-linux-gnueabi.h are strictly equivalent, right? So why not doing that until the final fix is implemented?

This case can be solved quickly using symbolic links at least for the ARM platform, whether it be upstream or here on Gentoo. I do like splitting hairs at times (I really do) but one year *without* anything that works is not going to make it. Better a few working cases than none at all.
Comment 9 Vince C. 2015-09-12 10:54:46 UTC
(In reply to Vince C. from comment #8)

> Obviously lock-obj-pub.arm-unknown-linux-gnueabihf.h and
> lock-obj-pub.armv7a-hardfloat-linux-gnueabi.h are strictly equivalent

... meaning arm-unknown-linux-gnueabihf and armv7a-hardfloat-linux-gnueabi are obviously equivalent triplets, of course. Anyway, if the supplied lot of triplet-depending files is exhaustive, there's a good reason a file-mapping can be done regardless of how Gentoo names its triplets.
Comment 10 Alon Bar-Lev (RETIRED) gentoo-dev 2015-09-12 13:44:02 UTC
Gentoo is not upstream, please contact upstream.
Upstream does not provide any sensible solution, see $URL.
Comment 11 Vince C. 2015-09-12 16:57:43 UTC
(In reply to Alon Bar-Lev from comment #10)
> Gentoo is not upstream, please contact upstream.
> Upstream does not provide any sensible solution, see $URL.

Not because Gentoo is not upstream (which I don't need to reminded) is no reason to stubbornly stagnate, all camps. It only takes one good-willing person to make the schmilblick progress. Shall we decide there will be none?

I've see so many discussions about distro maintainers making their own patches without feeding upstream being far from uncommon. Now no one should want to make a patch because upstream wouldn't make a sensible solution...!?

C'm'on, let's be smarter than that. I'm just an average idiot yet I did something to make it work. So, yes, we can and I'm not just paraphrasing.