Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 737888 - >=gnome-base/librsvg-2.48.8 - fails to cross compile with cross-emerge wrappers: error: Error loading target specification
Summary: >=gnome-base/librsvg-2.48.8 - fails to cross compile with cross-emerge wrappe...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
Depends on:
Reported: 2020-08-18 12:25 UTC by tt_1
Modified: 2020-08-18 13:36 UTC (History)
1 user (show)

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

build.log (build.log,31.64 KB, text/plain)
2020-08-18 12:25 UTC, tt_1
output from emerge --info (cross-target) (emerge-info,4.86 KB, text/plain)
2020-08-18 12:26 UTC, tt_1
this patch works for me (ebuild.patch,472 bytes, patch)
2020-08-18 13:10 UTC, tt_1
Details | Diff
reduced patch (updated-patch.patch,448 bytes, patch)
2020-08-18 13:36 UTC, tt_1
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description tt_1 2020-08-18 12:25:16 UTC
Created attachment 655320 [details]

cross compiling is a bit more difficult with rust based toolchain, but I do have all the good stuff from dev-lang/rust-1.44.1 ebuild, where cross compile support was added: 


still, the ebuild fails to recognize it: 

error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --target armv7a-unknown-linux-gnueabihf --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit code: 1)
--- stderr
error: Error loading target specification: Could not find specification for target "armv7a-unknown-linux-gnueabihf". Use `--print target-list` for a list of built-in targets

make[2]: *** [Makefile:1761:] Error 101
Comment 1 tt_1 2020-08-18 12:26:07 UTC
Created attachment 655322 [details]
output from emerge --info (cross-target)
Comment 2 Mart Raudsepp gentoo-dev 2020-08-18 12:42:17 UTC
CCing gyakovlev for potential advice
Comment 3 Mart Raudsepp gentoo-dev 2020-08-18 12:43:27 UTC
Restoring useful bug summary
Comment 4 tt_1 2020-08-18 13:10:52 UTC
Created attachment 655324 [details, diff]
this patch works for me

the new build system is a bit whacky, it seems to expect --host=${CHOST_default} when cross compiling with cross-emerge wrappers to find all of the cross compiler tools (gcc/g++/ar/nm)

normally I'd expect --host to be a value of x86_64 when cross compiling from amd64 to armv7a, but little do I know it seems. 

maybe you can find a more fine tuned solution, but this patch is good enough for me:

file /usr/armv7a-unknown-linux-gnueabihf/usr/lib/ 
/usr/armv7a-unknown-linux-gnueabihf/usr/lib/ ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped

if you agree, please allow me some time to test with some more cross compile chains
Comment 5 Mart Raudsepp gentoo-dev 2020-08-18 13:24:31 UTC
!multilib_is_native_abi case already does a lot of that. If multilib_is_native_abi isn't false on cross-compiling (isn't it?), then maybe we can just do a logical OR there for cross-compiler too, and unconditionally add --host passing or something?
Comment 6 tt_1 2020-08-18 13:36:37 UTC
Created attachment 655326 [details, diff]
reduced patch

I removed the third line and got away with it. 

you see, this is really strange build system. It defines multilib as cross compiling, and for true cross-arch compiling it want's to see --host switch. 

and it seems to me that cross compiling from amd64 to armv7 doesn't pick up anything of the array behind 	

if ! multilib_is_native_abi; then 

from line 57