gcc-5.4.0 doesn't compile (inside and outside of chroot)

musv · Advocate Joined: 01 Dec 2002 Posts: 3365 Location: de

Grml, always new problems appear on my hard way to get the arm stuff running. Now gcc won't compile.

First of all my make.conf of the cross environment:

musv · Advocate Joined: 01 Dec 2002 Posts: 3365 Location: de

Got it compiled.

I compiled the whole system already with gcc-5.4.0 from outside the chroot via cross-compiler. And then I compiled gcc-5.4.0 inside the qemu-arm chroot, which took several hours. But finally it worked.

apyh · n00b Joined: 17 Mar 2003 Posts: 70 Location: Texas

musv,

What wiki or guide are you using for setting up your cross-environment? I've been stuck following this guide: https://wiki.gentoo.org/wiki/Cross_build_environment at the arm-bla-blah-emerge @system --keep-going for a while, it fails to compile about 16 packages including sys-apps/file and dev-lang/python, which make emerge useless once i try and chroot. =(

musv · Advocate Joined: 01 Dec 2002 Posts: 3365 Location: de

apyh:

Cross-Compiling on Gentoo is very frustrating. I used also the guide you posted.

I'm at the point to configure and compile the kernel, so the base system has been finished. Some points:

I started with gcc-4.xx as the cross-compiler and built the environment to the point to be able to compile gcc-5.x inside the chroot. Building gcc-5.x on the host didn't work for me. As soon as finished building gcc I switched to gcc-5.x outside (cross) and inside (native) the chroot.
The main problem is that some packages fail to compile with complaining no to find some gcc parameters (armv7-a, neon, abifloat=hard). In this case you have to compile those packages inside the chroot.
With stable arm I failed to build the base system very early. Switching to ~arm some problems are gone.
If a package fail, you should look into the configure log files. Many times the actual error is different to the shown error in the console.
If you look into my USE flags, you'll find a lot of deactivated flags. To get a complete base system, deactivate some of the default flags to reduce the dependencies. If you have managed to compile the base system and have a working chroot, activate the flags one by one and re-compile the affected packages.
If you have problems to switch into the chroot, check my other thread. I don't use the binmft service anymore. Instead I write the "magical byte code" directly to the proc system. So I can specify the path to the qemu-wrapper. If you use the binmft-service, it point's to qemu-arm. Hence the cpu architecture is only set to arm and not to armv7-a.

Hope it helps.

apyh · n00b Joined: 17 Mar 2003 Posts: 70 Location: Texas

I got gcc compiled out of chroot (4.9.3), which gave me some hope. But after entering the chroot and trying to run env-update, i get this error =(

musv · Advocate Joined: 01 Dec 2002 Posts: 3365 Location: de

I stumbled into the same problem and created this bug-report:

https://bugs.gentoo.org/show_bug.cgi?id=591878

Portage installs the files into:
/usr/armv7a-hardfloat-linux-gnueabi/usr/lib64/python3.4/site-packages/portage

So copy the contents from
/usr/armv7a-hardfloat-linux-gnueabi/usr/lib64
to
/usr/armv7a-hardfloat-linux-gnueabi/usr/lib

and set afterwards a symlink from the lib64 to the lib directory. But use a relative path not an absolute, so it can work from inside and outside of chroot.

apyh · n00b Joined: 17 Mar 2003 Posts: 70 Location: Texas

ack, i thought i created that symlink! but that must've been a earlier try. looks like chroot is working now, thanks!