| View previous topic :: View next topic |
| Author |
Message |
fanthom
n00b
Joined: 31 May 2007
Posts: 60
|
 Posted: Sat Jan 27, 2018 10:25 pm Post subject: [ SOLVED] Cross compilation errors |
 |
|
I'm getting many cross compiled packages failing for:
| Code: | | /lib/ld-linux-aarch64.so.1: No such file or directory |
My /usr/aarch64-unknown-linux-gnu/etc/portage/make.conf has correct entries:
| Code: | CHOST=aarch64-unknown-linux-gnu
ARCH=arm64
CBUILD=x86_64-pc-linux-gnu
HOSTCC=x86_64-pc-linux-gnu-gcc
ROOT=/usr/${CHOST}/
PKGDIR=${ROOT}packages/
PORTAGE_TMPDIR=${ROOT}tmp/
PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/" |
If i copy '/usr/aarch64-unknown-linux-gnu/lib64' to /lib then installation moves forward a bit but fails again for "missing" libs from '/usr/aarch64-unknown-linux-gnu/usr/lib64'.
I cant copy these to /usr/lib as gcc stops working.
Would be grateful for any tips how to resolve this.
Thank you.
Last edited by fanthom on Tue Jan 30, 2018 1:18 pm; edited 1 time in total |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54673
Location: 56N 3W
|
| Posted: Sat Jan 27, 2018 10:42 pm Post subject: |
|
|
fanthom,
What you have posted looks correct.
| fanthom wrote: | | If i copy '/usr/aarch64-unknown-linux-gnu/lib64' to /lib |
That would be /lib on your host?
Thats a bad thing ... unless you intended the destination to be /usr/aarch64-unknown-linux-gnu/lib and its still a bad thing, you don't need to do that.
Tell how you generated your /usr/aarch64-unknown-linux-gnu/
Tell how you are building things there.
What is your /usr/aarch64-unknown-linux-gnu/etc/portage/make.profile symbolic link pointing to?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
fanthom
n00b
Joined: 31 May 2007
Posts: 60
|
| Posted: Sun Jan 28, 2018 8:58 am Post subject: |
|
|
"That would be /lib on your host? "
Yes
"Tell how you generated your /usr/aarch64-unknown-linux-gnu/"
I have just started from scratch to make sure everything is done correctly and i'm able to reproduce this bug quickly.
I have followed these docs:
https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-compiler
https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Cross-compiling_with_Portage
Basically i run:
| Code: | | crossdev -S -t aarch64 |
Then i modified /usr/aarch64-unknown-linux-gnu/etc/portage/make.conf to this one:
| Code: |
CHOST=aarch64-unknown-linux-gnu
ARCH=arm64
CBUILD=x86_64-pc-linux-gnu
HOSTCC=x86_64-pc-linux-gnu-gcc
ROOT=/usr/${CHOST}/
PKGDIR=${ROOT}packages/
PORTAGE_TMPDIR=${ROOT}tmp/
PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
MAKEOPTS="-j8"
CFLAGS="-O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
ELIBC="glibc"
ACCEPT_KEYWORDS="arm64 ~arm64"
FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
PORTDIR="/home/cache/portage"
DISTDIR="/home/cache/portage/distfiles"
PORTDIR_OVERLAY="/var/overlay"
L10N="en"
LINGUAS="en"
PYTHON_TARGETS="python2_7"
PYTHON_SINGLE_TARGET="python2_7"
USE="${ARCH} -acl -berkdb -cracklib -cramfs -crypt -debug -introspection -ipv6 -ncurses -nls -orc -pam -pcre -python3 -readline -suid -tcpd -unicode -xattr cacert cups dbus -dri -llvm minimal -nsplugin -opengl pic udev"
INPUT_DEVICES="evdev"
VIDEO_CARDS="fbdev"
EMERGE_DEFAULT_OPTS="-j4"
#EMERGE_DEFAULT_OPTS="--quiet-build=n"
|
and created a "make.profile" symlink to:
/home/cache/portage/profiles/default/linux/arm64/17.0
Once done i run:
| Code: | | aarch64-unknown-linux-gnu-emerge -v --root-deps @system |
First failure is related to sys-apps/diffutils (had to mask newest diffutils-3.6) and second failure occurs on sys-devel/flex-2.6.4-r1.
Once i masked flex-2.6.4-r1 emerge tries to compile older version: flex-2.6.3-r1 and this is where i'm getting linking error:
| Code: | /bin/sh ../libtool --tag=CC --mode=link aarch64-unknown-linux-gnu-gcc -O2 -pipe -fomit-frame-pointer -Wl,-O1 -Wl,--as-needed -o stage1flex stage1flex-scan.o stage1flex-buf.o stage1flex-ccl.o stage1flex-dfa.o stage1flex-ecs.o stage1flex-filter.o stage1flex-gen.o stage1flex-main.o stage1flex-misc.o stage1flex-nfa.o stage1flex-options.o stage1flex-parse.o stage1flex-regex.o stage1flex-scanflags.o stage1flex-scanopt.o stage1flex-skel.o stage1flex-sym.o stage1flex-tables.o stage1flex-tables_shared.o stage1flex-tblcmp.o stage1flex-yylex.o -lm
libtool: link: aarch64-unknown-linux-gnu-gcc -O2 -pipe -fomit-frame-pointer -Wl,-O1 -o stage1flex stage1flex-scan.o stage1flex-buf.o stage1flex-ccl.o stage1flex-dfa.o stage1flex-ecs.o stage1flex-filter.o stage1flex-gen.o stage1flex-main.o stage1flex-misc.o stage1flex-nfa.o stage1flex-options.o stage1flex-parse.o stage1flex-regex.o stage1flex-scanflags.o stage1flex-scanopt.o stage1flex-skel.o stage1flex-sym.o stage1flex-tables.o stage1flex-tables_shared.o stage1flex-tblcmp.o stage1flex-yylex.o -Wl,--as-needed -lm
./stage1flex -o stage1scan.c /usr/aarch64-unknown-linux-gnu/tmp/portage/sys-devel/flex-2.6.3-r1/work/flex-2.6.3/src/scan.l
/lib/ld-linux-aarch64.so.1: No such file or directory
make[2]: *** [Makefile:1627: stage1scan.c] Error 255
make[2]: Leaving directory '/usr/aarch64-unknown-linux-gnu/tmp/portage/sys-devel/flex-2.6.3-r1/work/flex-2.6.3-.arm64/src'
make[1]: *** [Makefile:524: all] Error 2
make[1]: Leaving directory '/usr/aarch64-unknown-linux-gnu/tmp/portage/sys-devel/flex-2.6.3-r1/work/flex-2.6.3-.arm64/src'
make: *** [Makefile:526: all-recursive] Error 1 |
I guess in case of flex-2.6.3-r1 (and many other packages later on) aarch64-unknown-linux-gnu-emerge for reason does not respect 'ROOT=/usr/${CHOST}/' variable from make.conf and tries to link it from the host system.
Any idea why?
Maybe would be easier to unpack stage3:
http://distfiles.gentoo.org/releases/arm/autobuilds/20161219/stage3-arm64-20161219.tar.bz2
to /usr/aarch64-unknown-linux-gnu and then run 'aarch64-unknown-linux-gnu-emerge -v --root-deps -e world' to recompile everything to latest version? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54673
Location: 56N 3W
|
| Posted: Sun Jan 28, 2018 12:05 pm Post subject: |
|
|
fanthom,
It looks like it should work but not all packages will cross compile.
is not going to get you very far.
As arm64 is experimental on Gentoo, only the system set is marked stable.
You will need
-- edit --
Heres how I did what you are trying to do and what worked and what didn't.
My cross make.conf contains
| Code: | ############################################################################
# Where to find C and C++ KEEP THIS UP TO DATE!!! Contains version numbers.
# Fixes broken build systems that try to use the native compiler
CXX="/usr/x86_64-pc-linux-gnu/aarch64-unknown-linux-gnu/gcc-bin/7.1.0/aarch64-unknown-linux-gnu-g++"
CC="/usr/x86_64-pc-linux-gnu/aarch64-unknown-linux-gnu/gcc-bin/7.1.0/aarch64-unknown-linux-gnu-gcc"
LD="/usr/x86_64-pc-linux-gnu/aarch64-unknown-linux-gnu/binutils-bin/2.27/ld.gold"
AR="/usr/x86_64-pc-linux-gnu/aarch64-unknown-linux-gnu/gcc-bin/7.1.0/aarch64-unknown-linux-gnu-gcc-ar"
########################################################################### |
To point some of the more gently broken build systems in the right direction.
Notice that the paths contain version numbers, so these paths need to be edited to keep them in sync with whatever the system uses.
Its a lot easier to start with a stage3.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
fanthom
n00b
Joined: 31 May 2007
Posts: 60
|
| Posted: Sun Jan 28, 2018 5:46 pm Post subject: |
|
|
Just figured out that emerge tries to run './stageflex' in the source directory in order to continue compilation:
| Code: | ./stage1flex -o stage1scan.c /usr/aarch64-unknown-linux-gnu/tmp/portage/sys-devel/flex-2.6.3-r1/work/flex-2.6.3/src/scan.l
/lib/ld-linux-aarch64.so.1: No such file or directory |
And obviously that fails without chroot/native compilation.
Must use qemu in this case.
Thanks |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22938
|
| Posted: Sun Jan 28, 2018 6:35 pm Post subject: |
|
|
| That is a bug in the build system. It should have built with the native compiler for that program, so that the program could be run on the build host. It should still use the cross-compiler for all programs to be installed on the target machine. |
|
| Back to top |
|
|
fanthom
n00b
Joined: 31 May 2007
Posts: 60
|
| Posted: Sun Jan 28, 2018 9:12 pm Post subject: |
|
|
Thanks Hu,
Is there a known fix for this bug? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54673
Location: 56N 3W
|
| Posted: Sun Jan 28, 2018 9:17 pm Post subject: |
|
|
fanthom,
This may seem cruel but its all a part of your cross compile learning experience.
Have a look at bugs.gentoo.org. File a new bug if there is no bug already.
If its a known bug with a fix, the fix may be on the bug.
It may be fixed in a newer version too.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
fanthom
n00b
Joined: 31 May 2007
Posts: 60
|
| Posted: Tue Jan 30, 2018 1:17 pm Post subject: |
|
|
I'm not sure if crossdev is meant to compile every single package. I found bugs for crossdev which are 8 and even 10 years old.
I took different approach which works.
I have compiled @system with crossdev (after upgrading to testing version of crossdev everything compiles just fine) and then compiled my world natively on my Amlogic 905W box.
Surprised to see that every single package compiled correctly. OTOH - i use openbox only so no big dependencies to pull.
Giving SOLVED as in my opinion my initial approach was incorrect (compiling everything with crossdev).
Thank you for the help provided. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54673
Location: 56N 3W
|
| Posted: Tue Jan 30, 2018 1:35 pm Post subject: |
|
|
fanthom,
Once you have a working cross toolchain, its only a small step to add in distcc.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22938
|
| Posted: Wed Jan 31, 2018 3:31 am Post subject: |
|
|
| Ideally, every single package should cross-compile cleanly. In practice, that requires considerably more care than a native compilation, so it's relatively common to find people who can write a package that native-compiles, but less common to find people who can write a package that cross-compiles, particularly as complexity increases. For example, if the package needs to know properties of the runtime environment, it cannot be cross-compile-compatible if it detects those properties by running a test program. Instead, it must be given those values externally or it must derive them by building/linking, but not running, a test program. That requires more thought to get right, and sometimes is impractical or impossible. Hence, packages that do not cross-compile cleanly. |
|
| Back to top |
|
|
fanthom
n00b
Joined: 31 May 2007
Posts: 60
|
| Posted: Wed Jan 31, 2018 8:17 pm Post subject: |
|
|
@NeddySeagoon
I would need at least two ARM boxes for distcc if i understand correctly. Have only one. Unless i can mix native compilation with crossdev?
That would be blast! (i guess its not possible though)
@Hu
Thanks for explanation. I was thinking the same. Still grateful to crossdev developers/maintainers as i can compile @system on my PC and then world natively.
Kernel should be easier (currently chrooting from modified LibreELEC) and all pieces are set 
Thanks |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54673
Location: 56N 3W
|
| Posted: Wed Jan 31, 2018 8:25 pm Post subject: |
|
|
fanthom,
I have a Raspberry Pi 3 in aarch64 mode and an amd64 system with | gcc-config -l: | | [4] aarch64-unknown-linux-gnu-7.3.0 * |
When the Raspberry Pi distcc distributes to the amd64 system, the selected cross aarch64-unknown-linux-gnu compiler is called and the Pi 3 gets aarch64 code back.
Everyone is happy.
Unfortunately, its a user problem to keep all the helpers gcc at the same version. distcc passes the compiler name, hence cross distcc just works, but not the version.
Setting up a working cross tool chain is the hard bit and you have done that.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
|
Gentoo on ARM
