Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
cross compile for powerpc on x86_64, crossdev chroot?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on PPC
View previous topic :: View next topic  
Author Message
Pipeline79
n00b
n00b


Joined: 17 Feb 2020
Posts: 4
Location: United Kingdom

PostPosted: Mon Feb 17, 2020 7:03 pm    Post subject: cross compile for powerpc on x86_64, crossdev chroot? Reply with quote

Hi there,

I have an imac-g5, so ppc64, running gentoo which is taking a really long time today to build firefox with optimization flags. Ridiculously long and using up lots of swap.

I was wondering if I could use distcc with portage to speed things up. My laptop is decent, with quite a speedy ivybridge cpu, but it's running slackware natively and gcc is series 5 at the moment.
GCC is 8.3 on the imac. They're both on the same LAN. If the laptop was running Gentoo then the instructions for crossdev to install a powerpc toolchain would be easy, but it's not.
Can I run crossdev in a gentoo chroot and then set that up as the distcc host/client for the imac target?

Or is the reason why all the info I've been able to google relates to qemu in a chroot for distcc because the remote compiler needs a particular ip address?

It seems to be the linking that's got stuck. I used the custom-optimization, custom-cflags & lto flags hoping it would build a faster firefox binary.

Cheers.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46103
Location: 56N 3W

PostPosted: Mon Feb 17, 2020 8:07 pm    Post subject: Reply with quote

Pipeline79,

Welcome to Gentoo.

The problem with Gentoo in a chroot on helpers is just as you describe. The system outside the chroot won't know about the compiler inside the chroot.
A Virtual Machine works though, as to all intends and purposes, its another system on your LAN, with its own IP.

Firefox is bad news for lots of reasons. It depends on rust, which is not a language that distcc can distribute. Its not all rust, fh. C/C++ will be sent to the helper(s)
With distcc, the configure, preprocess and link steps still take place on the weaker system.
Linking needs lots of RAM.

You could create a ppc64 chroot on your laptop and have your ivybridge CPU execute QEMU to run ppc64 code.
That has its drawbacks. Its slow, as the ppc64 is emulated in software but it can use all your RAM, so less or no swapping.
You would build your own ppc64 binaries, then install your binaries on your imac-g5.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Pipeline79
n00b
n00b


Joined: 17 Feb 2020
Posts: 4
Location: United Kingdom

PostPosted: Wed Feb 19, 2020 2:19 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Pipeline79,

Welcome to Gentoo.

The problem with Gentoo in a chroot on helpers is just as you describe. The system outside the chroot won't know about the compiler inside the chroot.
A Virtual Machine works though, as to all intends and purposes, its another system on your LAN, with its own IP.

Firefox is bad news for lots of reasons. It depends on rust, which is not a language that distcc can distribute. Its not all rust, fh. C/C++ will be sent to the helper(s)
With distcc, the configure, preprocess and link steps still take place on the weaker system.
Linking needs lots of RAM.

You could create a ppc64 chroot on your laptop and have your ivybridge CPU execute QEMU to run ppc64 code.
That has its drawbacks. Its slow, as the ppc64 is emulated in software but it can use all your RAM, so less or no swapping.
You would build your own ppc64 binaries, then install your binaries on your imac-g5.


Thanks for your reply Neddy,

Before I read your reply I thought I'd be clever and try creating a gentoo LXC container on my laptop and see if I could get it to crossdev for ppc64 over distcc by combining your wiki instructions for the raspberry pi and this post here: https://forums.gentoo.org/viewtopic-t-1056580-start-0.html

Its networking is OK, I can ping and ssh into it from the imac target with an assigned static address and a route. I can emerge the crossdev, ccache and distcc packages inside the container and build a crossdev environment with the crossdev tool and a powerpc64-unknown-linux-gnu tuple. However, I've tried configuring the distccd on both machines to accept connections from each other and enabled distcc in portage and so far they don't seem to be sharing jobs. I don't know if what I'm trying is not actually possible, or I am just missing something in my configuration.

The setup that the poster I mentioned was using was actually for 2 x86 machines, and he used ubuntu containers with a gentoo target. In your article you're compiling for the pi from a system that is natively running gentoo. I don't know if the reason my idea won't work is because the container is x86_64 itself - I can't choose a ppc64 container architecture, the closest would be ppc64el, which I think means power9 or talos. Also, some crossdev guides on the wiki suggest changing the portage 'profile' for the build environment to the target arch, which may not be possible inside a container.

I'd be happy trying to build packages either using the method you described, or creating a minimal gentoo install on a new partition, if that would work better for most things. Like in your raspeberry pi example.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46103
Location: 56N 3W

PostPosted: Wed Feb 19, 2020 6:51 pm    Post subject: Reply with quote

Pipeline79,

It sounds like you are putting all the the pieces together, standing back a safe distance, then lighting the blue touch paper.
Gentoo does not respond well to that approach. Baby steps ... build on what you know works.

Step 1, on the imac-g5, install distcc, configure it to listen for pleas for help but to its own IP address.
This is not useful long tern but you can use this setup to test the imac-g5 distcc configuration.

Step 2. Do the same thing inside the LXC container.

When that works, you have distccc set up to help itself on both systems.
You don't use the cross compiler in the LXC container yet. You are really only testing the setup. That you will call a cross compile via distcc doesn't matter yet.

Step 3.
In the LXC container, set up your /usr/powerpc64-unknown-linux-gnu/etc/portage almost as it in the the imacs /etc/portage.
Take care with the make.profile symlink and the PACKAGES path in /usr/powerpc64-unknown-linux-gnu/etc/portage/make.conf
The CHOST remains unchanged too.

This step will make a binary package or two for the imac and you really don't want to overwrite your host packages.

Do
Code:
emerge-wrapper -t powerpc64-unknown-linux-gnu --init
powerpc64-unknown-linux-gnu-emerge glibc

This will test your cross compiler. It will try to build glibc with the setting provided in /usr/powerpc64-unknown-linux-gnu/etc/portage/*
If it works glibc will be installed there and you will have a binary package you can install and execute on the imac too.

I chose glibc as an example because every time Linux is brought up on a new architecture, The kernel and glibc are cross compiled this way, so both are known to work.
Now you know your cross toolchain works too.

Step 4. Put the working pieces together.
On the imac, change the /etc/distcc/hosts file to point to the LXC container and stop distccd.
distccd is the bit that listens for cries for help, so its not needed here.
In the LXC container, set up /etc/conf.d/distccd to listen to the imac and restart distccd if it was running. Start it if it wasn't

Check that the imac has FEATURES=disctcc in its make.conf
Check that you have identical powerpc64-unknown-linux-gnu compiler versions both places.

On the imac, run
Code:
emerge -1av glibc

Post any error messages.
Again, glibc is a good test case.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Pipeline79
n00b
n00b


Joined: 17 Feb 2020
Posts: 4
Location: United Kingdom

PostPosted: Wed Feb 19, 2020 9:29 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Pipeline79,

It sounds like you are putting all the the pieces together, standing back a safe distance, then lighting the blue touch paper.
Gentoo does not respond well to that approach. Baby steps ... build on what you know works.



Yep, that's a pretty good description...

Thanks for giving me a roadmap to work to, I will follow your advice.

Much appreciated.
Back to top
View user's profile Send private message
Pipeline79
n00b
n00b


Joined: 17 Feb 2020
Posts: 4
Location: United Kingdom

PostPosted: Thu Feb 27, 2020 9:14 pm    Post subject: Reply with quote

Quote:
Step 3.
In the LXC container, set up your /usr/powerpc64-unknown-linux-gnu/etc/portage almost as it in the the imacs /etc/portage.
Take care with the make.profile symlink and the PACKAGES path in /usr/powerpc64-unknown-linux-gnu/etc/portage/make.conf
The CHOST remains unchanged too.


So, I used the same USE flags, CFLAGS, etc.
The make.profile symlink was pointing to 'embedded' in /var/db/repos/gentoo/profiles , I presume that was what the crossdev setup (for ppc) had done, so I left it at that.
I have CHOST=powerpc64-unknown-linux-gnu and CBUILD=x86_64-pc-linux-gnu --- hope I didn't screw that up.

The next step builds glibc and some others for me successfully in overlay (/usr/powerpc64-unknown-linux-gnu/) root /packages.
I sftp the glibc.tbz2 to the imac and put it in my /usr/portage/packages directory (which didn't exist before, but was specified in the make.conf. Maybe should be in /var/cache/binpkgs/ now?

emerge --usepkgonly -1av =glibc-xxx

now installs the binary package, but has to generate 487 locales on the host. Perhaps should have brought over the built dependency packages too?

It's still generating them as I type this. So, that's where I've got to so far. The crossdev appears to be working, unless it's possible to emerge an 'incorrect' binary package and break the system.
I wanted to include the verbose information that portage reported about the glibc package, but it's gone off the screen now.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46103
Location: 56N 3W

PostPosted: Thu Feb 27, 2020 9:37 pm    Post subject: Reply with quote

Pipeline79,

You have different /etc/locale.gen on the I-mac and in the ppc target root
That files governs what locales will be built with glibc.

The embedded profile in the target root is in general, not useful. The /etc/portage/make.profile symlink on the I-mac needs to be copied to the ppc target root.
On the I-mac, its a relative link.
My amd64 has
Code:
/etc/portage/make.profile -> ../../usr/portage/profiles/default/linux/amd64/17.0/no-multilib

If you want to keep it a relative link in the target root you either need to bind mount the hosts /usr/portage inside the target root or add ../../ to the front of the path.

You should fix that as the profile provides a set of default USE flays and the USE flags need to be the same in both places.

Crossdev sets the embedded profile for all arches and almost nobody want to use it.

Provided glibc works, your test passed. The /etc/locale.gen is a detail.

On the I-mac, stop distccd.
Point its /etc/distcc/hosts at the helper.
You don't need to include the I-mac here. It will be used as a fallback anyway.
Check that your I-mac gcc version is the same as the cross compiler version.

Enjoy cross distcc.

If you want to see it working, run the monitor on the I-mac.
Only compiles get distributed, so don't be disappointed to see nothing for a while.

-- edit --

Add distcc to FEATURES on the I-mac.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 46103
Location: 56N 3W

PostPosted: Fri Feb 28, 2020 6:01 pm    Post subject: Reply with quote

Pipeline79,

Did you get my edit above?

Add distcc to FEATURES on the I-mac.
That's how portage knows to use distcc.

When the i-mac asks for help it will pass powerpc64-unknown-linux-gnu as part of its request.
Unfortunately, it can't ask for a specific version.

It uses whatever version is set in the helpers gcc-config an the active powerpc64-unknown-linux-gnu.

You can have lots of cross compilers and target roots on your helpers
Code:
$ gcc-config -l
 [1] aarch64-unknown-linux-gnu-8.3.0
 [2] aarch64-unknown-linux-gnu-9.2.0 *

 [3] armv6j-hardfloat-linux-gnueabi-8.3.0
 [4] armv6j-hardfloat-linux-gnueabi-9.2.0 *

 [5] armv7a-hardfloat-linux-gnueabi-8.3.0
 [6] armv7a-hardfloat-linux-gnueabi-9.2.0 *

 [7] avr-8.3.0
 [8] avr-9.2.0 *

 [9] i586-pc-linux-gnu-8.3.0
 [10] i586-pc-linux-gnu-9.2.0 *

 [11] i686-pc-linux-gnu-8.3.0
 [12] i686-pc-linux-gnu-9.2.0 *

 [13] mips64el-unknown-linux-gnu-8.3.0
 [14] mips64el-unknown-linux-gnu-9.2.0 *

 [15] powerpc-unknown-linux-gnu-8.3.0
 [16] powerpc-unknown-linux-gnu-9.2.0 *

 [17] x86_64-pc-linux-gnu-8.3.0
 [18] x86_64-pc-linux-gnu-9.2.0 *
The version with the * will be used.
The native compiler has a green *. The cross compiler(s) have a cyan *.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on PPC All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum