| View previous topic :: View next topic |
| Author |
Message |
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
 Posted: Thu Feb 09, 2017 3:58 pm Post subject: [SOLVED] Crossbuild to aarch64 fails for libxcb. |
 |
|
Rather confused. Based on the existence of a prebuilt image and an experimental branch, this should work. I am following this and this. Host is an amd64 computer, build command is:
| Code: | | ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- aarch64-unknown-linux-gnu-emerge -uDNa @world |
The profile is 13.0/desktop for arm64.
| Code: | * Package: x11-libs/libxcb-1.12-r2
* Repository: gentoo
* Maintainer: x11@gentoo.org
* USE: arm64 elibc_glibc kernel_linux userland_GNU xkb
* FEATURES: preserve-libs sandbox userpriv usersandbox
* No Python implementation found for the build. This is usually
* a bug in the ebuild. Please report it to bugs.gentoo.org
* along with the build log.
* ERROR: x11-libs/libxcb-1.12-r2::gentoo failed (setup phase):
* No supported Python implementation installed.
*
* Call stack:
* ebuild.sh, line 115: Called pkg_setup
* libxcb-1.12-r2.ebuild, line 42: Called python-any-r1_pkg_setup
* python-any-r1.eclass, line 343: Called python_setup
* python-any-r1.eclass, line 331: Called die
* The specific snippet of code:
* die "No supported Python implementation installed."
*
* If you need support, post the output of `emerge --info '=x11-libs/libxcb-1.12-r2::gentoo'`,
* the complete build log and the output of `emerge -pqv '=x11-libs/libxcb-1.12-r2::gentoo'`.
* The complete build log is located at '/usr/aarch64-unknown-linux-gnu/tmp/portage/x11-libs/libxcb-1.12-r2/temp/build.log'.
* The ebuild environment file is located at '/usr/aarch64-unknown-linux-gnu/tmp/portage/x11-libs/libxcb-1.12-r2/temp/die.env'.
* Working directory: '/usr/lib64/python3.4/site-packages'
* S: '/usr/aarch64-unknown-linux-gnu/tmp/portage/x11-libs/libxcb-1.12-r2/work/libxcb-1.12' |
Last edited by R0b0t1 on Fri Feb 10, 2017 2:54 am; edited 3 times in total |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Thu Feb 09, 2017 4:51 pm Post subject: |
|
|
R0b0t1,
If you made your cross compiler with crossdev -t aarch64-unknown-linux-gnu your host target is in /usr/aarch64-unknown-linux-gnu
This is the top of a Gentoo arm64 root filesystem, complete with its /etc/portage.
You need to configure this /etc/portage for cross compiling.
The /etc/portage/make.profile set here by default will probably stop most emerges working. Set one of the arm64 profiles by changing the symlink manually.
I have | Code: | $ ls /usr/aarch64-unknown-linux-gnu/etc/portage/make.profile -l
lrwxrwxrwx 1 root root 54 Mar 31 2016 /usr/aarch64-unknown-linux-gnu/etc/portage/make.profile -> /usr/portage/profiles/default/linux/arm64/13.0/desktop |
There are a few more wrinkles. /usr/aarch64-unknown-linux-gnu is provided empty. Not even the @system set.
In theory you can do
| Code: | emerge-wrapper -t aarch64-unknown-linux-gnu --init
aarch64-unknown-linux-gnu-emerge @system |
and it all works.
The practice is quite different. The dependencies in the @system set packages may not be complete. Normally, that's OK as its always considered to be installed.
When you want to crosss emerge it from nothing, portage gets the order wrong so you have to have several goes.
Install an arm64 stage3 to /usr/aarch64-unknown-linux-gnu to get you going but beware its made with gcc-4.9, not gcc-5.4 so you have the C++ABI issue.
It gets worse. Some packages build code then run it, all as part of the build. Unfortunately, in your case, they will build arm64 code and try to run it on the build host.
That fails by design. Then there are all the broken build systems.
Here | Code: | | aarch64-unknown-linux-gnu-emerge x11-libs/libxcb |
-ave builds
Calculating dependencies... done!
| Code: | [ebuild R ] x11-proto/xproto-7.0.31::gentoo to /usr/aarch64-unknown-linux-gnu/ USE="(-doc)" 0 KiB
[ebuild R ] dev-libs/libpthread-stubs-0.3-r1::gentoo to /usr/aarch64-unknown-linux-gnu/ USE="-static-libs" 0 KiB
[ebuild R ] dev-libs/libbsd-0.8.3::gentoo to /usr/aarch64-unknown-linux-gnu/ USE="-static-libs" 0 KiB
[ebuild R ] x11-libs/libXdmcp-1.1.2-r1::gentoo to /usr/aarch64-unknown-linux-gnu/ USE="(-doc) -static-libs" 0 KiB
[ebuild R ] x11-libs/libXau-1.0.8::gentoo to /usr/aarch64-unknown-linux-gnu/ USE="-static-libs" 0 KiB
[ebuild R ] x11-libs/libxcb-1.12-r2:0/1.12::gentoo to /usr/aarch64-unknown-linux-gnu/ USE="xkb (-doc) (-selinux) -static-libs {-test}" 0 KiB |
correctly.
However, my /usr/aarch64-unknown-linux-gnu was not all obtained from cross compiling.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Thu Feb 09, 2017 5:03 pm Post subject: |
|
|
Moved from Installing Gentoo to Gentoo on Alternative Architectures.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Thu Feb 09, 2017 5:32 pm Post subject: |
|
|
EDIT: I have double checked. I ran:
| Code: | | cd /usr/aarch64-unknown-linux-gnu/etc/portage && rm make.profile && ln -s /usr/portage/profiles/default/linux/arm64/13.0/desktop make.profile |
Yet receive the message:
| Code: | !!! /etc/portage/make.profile is not a valid symlink and will likely prevent most merges.
!!! it should point into a profile within /usr/portage/profiles |
| NeddySeagoon wrote: | R0b0t1,
If you made your cross compiler with crossdev -t aarch64-unknown-linux-gnu your host target is in /usr/aarch64-unknown-linux-gnu
This is the top of a Gentoo arm64 root filesystem, complete with its /etc/portage.
You need to configure this /etc/portage for cross compiling.
The /etc/portage/make.profile set here by default will probably stop most emerges working. Set one of the arm64 profiles by changing the symlink manually.
I have | Code: | $ ls /usr/aarch64-unknown-linux-gnu/etc/portage/make.profile -l
lrwxrwxrwx 1 root root 54 Mar 31 2016 /usr/aarch64-unknown-linux-gnu/etc/portage/make.profile -> /usr/portage/profiles/default/linux/arm64/13.0/desktop |
|
This is indeed the case, though I will double check. The default setting was an embedded profile using busybox which seems to have built and installed properly. Just having removed and re-created the symlink I get a message from portage that the new symlink is, in fact, not a symlink into /etc/portage/profiles... I am extremely confused.
| NeddySeagoon wrote: |
There are a few more wrinkles. /usr/aarch64-unknown-linux-gnu is provided empty. Not even the @system set.
In theory you can do
| Code: | emerge-wrapper -t aarch64-unknown-linux-gnu --init
aarch64-unknown-linux-gnu-emerge @system |
and it all works.
The practice is quite different. The dependencies in the @system set packages may not be complete. Normally, that's OK as its always considered to be installed.
When you want to crosss emerge it from nothing, portage gets the order wrong so you have to have several goes.
Install an arm64 stage3 to /usr/aarch64-unknown-linux-gnu to get you going but beware its made with gcc-4.9, not gcc-5.4 so you have the C++ABI issue. |
Unfortunately no arm64 stage3 I could find is signed. That and other considerations lead me to want to compile my own. Moreover, I should be able to; someone did it originally. I hope this isn't seen as boneheadedness - I'm just confused as to why the process isn't working.
Having built a crossroot in the past I've encountered having to run emerge multiple times in a row, and each time more packages will complete. Unfortunately xcb was a recurring failure that seems it needed to be addressed. |
|
| Back to top |
|
|
chithanh
Developer
Joined: 05 Aug 2006
Posts: 2158
Location: Berlin, Germany
|
| Posted: Thu Feb 09, 2017 6:05 pm Post subject: |
|
|
| There are some issues with libxcb cross compiling currently, check bug 558774, bug 572732 and possibly others |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Thu Feb 09, 2017 6:22 pm Post subject: |
|
|
R0b0t1,
When I fixed my profile, I used full pathnames.
Have you moved your /usr/portage to someplace else?
You can get enough to boot into with a cross emerge. Don't use the desktop profile for that though as it will try to build bits of X which you don't care about yet.
Try default/linux/arm64/13.0 instead.
| Code: | | aarch64-unknown-linux-gnu-emerge -eav @system --keep-going --with-bdeps=y |
followed by multiple
| Code: | | aarch64-unknown-linux-gnu-emerge -uDNav @system --keep-going --with-bdeps=y |
should get you a large part of system.
Perl will not cross compile ang gcc is a challenge.
The stage1 and a few tools (bash?) must have been cross compiled originally but not the stage3.
Given a stage1, the rest could have been compiled in an emulator, that's effectively native.
See the Random Warnings And Caveats
That page is a year out of date. Ignore all the serial console and u-boot stuff.
The cross compiling @system from nothing is probably still valid.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Thu Feb 09, 2017 10:55 pm Post subject: |
|
|
| NeddySeagoon wrote: | R0b0t1,
When I fixed my profile, I used full pathnames.
Have you moved your /usr/portage to someplace else?
You can get enough to boot into with a cross emerge. Don't use the desktop profile for that though as it will try to build bits of X which you don't care about yet.
Try default/linux/arm64/13.0 instead.
| Code: | | aarch64-unknown-linux-gnu-emerge -eav @system --keep-going --with-bdeps=y |
followed by multiple
| Code: | | aarch64-unknown-linux-gnu-emerge -uDNav @system --keep-going --with-bdeps=y |
should get you a large part of system.
|
It turns out my base installation's /etc/portage/make.profile was invalid - I solved this with `eselect set profile`. I suppose I mistyped a command when trying to set up the crossroot. Thank you for the prompting to remove the desktop component. You're right that I don't need it at the moment; hopefully more of the base installation compiles. It may be necessary to build some packages on the device even though I want to avoid this as much as possible.
| NeddySeagoon wrote: |
Perl will not cross compile ang gcc is a challenge.
The stage1 and a few tools (bash?) must have been cross compiled originally but not the stage3.
Given a stage1, the rest could have been compiled in an emulator, that's effectively native.
|
I'm pretty sure I compiled Perl when using the embedded arm64 profile. I will try again with a more expansive profile. I'm getting file collisions and will try to resolve them with USE="-collision-detect -protect-owned". I suspect this may involve rolling back anything I did while using the embedded profile. Perhaps my compilation of things under the newer profile was using something like busybox which made them work. It may be worth noting this for future efforts.
| NeddySeagoon wrote: |
See the Random Warnings And Caveats
That page is a year out of date. Ignore all the serial console and u-boot stuff.
The cross compiling @system from nothing is probably still valid. |
Thank you for the tip. +1 for documenting Java installation. |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Fri Feb 10, 2017 1:15 am Post subject: |
|
|
Unsure if best course of action is to edit previous post or BUMP, but this may warrant a new thread.
Currently I'm experiencing issues emerging @system due to what I suspect is an unresolved circular dependency. coreutils depends on python depends on python-eselect depends on eselect depends on coreutils. Any fix? Will I need to use the unsigned stage3? Is building the packages from source an option? |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Fri Feb 10, 2017 2:54 am Post subject: |
|
|
| I had keyworded ~arm64 at the prompting of some guide. Removing it fixed the issue. A surprisingly large portion of @system built. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Fri Feb 10, 2017 11:02 am Post subject: |
|
|
R0b0t1,
That was my guide promting ~arm64.
The @system set on arm64 is stable but that's about all. After you have @system installed, you either use the ~arm64 keyword, or you do your own keywording.
icedtea and all the things it needs to build should be keyworded ~arm64 now, my github PR was accepted.
You just need to do the gcj:5.4.0, icedtea:7, icedtea:8 dance.
_________________
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
