| View previous topic :: View next topic |
| Author |
Message |
greyspoke
Apprentice
Joined: 08 Jan 2010
Posts: 175
|
 Posted: Sat Jan 18, 2025 1:48 pm Post subject: "cross-compiling" amd64 to i686 |
 |
|
I was set off down the path of using crossdev to compile for my i686 home server to get update times down to less than a week(!) when I was confronted with this message:
| Code: | * Refusing to create a cross-compiler using the same
* target name as your host utils.
* Consider using sys-devel/multilib-gcc-wrapper package.
|
With some more digging I found that crossdev deliberately does not regard what I am trying to do as sufficiently crossy for it. I mean, what's 32 bits among friends eh?
So should I follow the binary package guide and do it via chrooting? But multilib-gcc-wrapper doesn't seem to come into that. If I am to use multilib-gcc-wrapper, how exactly?
| Code: | ====== $ equery files multilib-gcc-wrapper
* Searching for multilib-gcc-wrapper ...
* Contents of sys-devel/multilib-gcc-wrapper-0-r2:
/usr
/usr/bin
/usr/bin/i686-pc-linux-gnu-c++
/usr/bin/i686-pc-linux-gnu-c++-14
/usr/bin/i686-pc-linux-gnu-cc
/usr/bin/i686-pc-linux-gnu-cpp
/usr/bin/i686-pc-linux-gnu-cpp-14
/usr/bin/i686-pc-linux-gnu-g++
/usr/bin/i686-pc-linux-gnu-g++-14
/usr/bin/i686-pc-linux-gnu-gcc
/usr/bin/i686-pc-linux-gnu-gcc-14
/usr/bin/i686-pc-linux-gnu-gfortran
/usr/bin/i686-pc-linux-gnu-gfortran-14
|
Which is all great I am sure but I really don't have a clue what to do with all that.
Thanks. |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54893
Location: 56N 3W
|
| Posted: Sat Jan 18, 2025 1:58 pm Post subject: |
|
|
greyspoke,
You can't create an i686 cross compiler on an amd64 multilib install as the toolchain can support both 64 bit and 32 bit code.
You pass -m32 or -m64 depending on what your want.
Its OK on a no-multilib install, as there is no 32 bit support at all.
You want Build In A Chroot
Beware what happens if the build system cannot execute all the instructions on the target
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
greyspoke
Apprentice
Joined: 08 Jan 2010
Posts: 175
|
| Posted: Sat Jan 18, 2025 3:13 pm Post subject: |
|
|
Thanks Neddy.
I don't have a multilib install so I will follow the instructions in your wiki page and make a chroot. And uninstall multilib-gcc-wrapper. Would -m32 get passed automatically to the compiler with a 32bit CHOST set, or would it have to go in CFLAGS? I assume that mounting parts of the slow computer filesystem on the fast computer is an alternative to syncing the portage trees and other stuff and having it access binary packages located on the fast computer via rsync etc.?
Thanks |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54893
Location: 56N 3W
|
| Posted: Sat Jan 18, 2025 4:39 pm Post subject: |
|
|
greyspoke,
crossdev detected a multilib install somehow, which is why in refused to make an i686 cross compiler.
The chroot with as install that mimics your server will produce 32 bit code anyway.
The compiler outside of the chroot will not be used.
In fact the chroot will be 32 bit only, everywhere.
As you say that you don't have a multilib install, your host kernel will need 32 bit support, or it won't run any 32 bit code.
That guide is a bit rough round the edges, which is why its still in my wiki namespace. Feedback welcome.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
greyspoke
Apprentice
Joined: 08 Jan 2010
Posts: 175
|
| Posted: Mon Feb 17, 2025 9:57 pm Post subject: |
|
|
Well that turned into a bit of an adventure.
Firstly, thank you for your help Neddy, as always, you are a star.
Of course my system was multilib, I was suffering from brain fade when I thought it wasn't. Just to backtrack a bit, the reason for wanting to do this was the thought of the system rebuild necessary to update the profile on the server to a 23.0 one. Whilst it no doubt is happy chuntering away with all 800 of its MHz and one processor, I am not so patient.
| Code: | Jan 12 13:15:51 2025 >>> sys-devel/gcc-13.3.1_p20241220
merge time: 2 days, 1 hour, 14 minutes and 53 seconds.
Wed Feb 12 18:22:53 2025 >>> sys-devel/gcc-13.3.1_p20241220
merge time: 3 minutes and 18 seconds. |
(The second one is the time to download and install the binary made on the desktop.)
So following your guide did not work as there are no suitable tarballs to start from - all the available ones are merged-usr whereas both my systems were still split-usr. After some faffing around I just transferred most of the operating system files from the server into the chroot (which included its split-usr profile). Just leaving out /dev, /sys, /proc, /tmp and /run and a lot of /var and of course tweaking some stuff in /etc/portage according to your guide. I could probably have done what follows via a more direct route, but following the profile update instructions I updated the profile on the chroot to a split-usr 23.0 profile (which involved a full rebuild which generated a full set of binaries), then did the same on the server, rebuilding from the binaries made on the chroot, then folllowing the instructions for merge-usr at https://wiki.gentoo.org/wiki/Merge-usr on the chroot then on the server. Interestingly, following this CHOST is not set at all make.conf in the chroot or on the server, I guess this is now set as part of the profile.
This all worked - compiling to 32 bit worked with no problems and the resulting binaries have been working on the server with no glitches. Yay! (I haven't tried compiling with the gcc made in the chroot yet, or using a kernel compiled there.)
I did run into a few issues still.
Firstly the server still used the old portage locations in /usr/portage rather than /var/cache, so I took the opportunity to change them to the modern locations.
Secondly, I couldn't persuade the server to sync with the gentoo repo on the desktop (my aim is to only update the repo on the desktop so keeping the three systems, desktop, chroot and server, in sync with each other). The issues were related to verification, probably solvable but I decided to try the alternative of mounting the desktop's gentoo repo on the server via nfs, which works well. I then found that if I did (might do this by mistake at some time) try to sync the server's gentoo repo, if I left "sync-uri" in /etc/portage/repos.conf/gentoo.conf out completely portage would sync with the default gentoo repo uri. But if I set sync-uri to "" then I got a polite message, but no syncing went on, which is fine. So I set this in the chroot as well.
Thirdly, at some time recently portage stopped transferring the binaries made (when buildpkg is set) to $PKGDIR locations which are nfs mounts. I still haven't got to the bottom of this, but as an alternative I left $PKGDIR in the chroot to the default local location and set an rsync uri to that on the server in /etc/portage/binrepos.conf/desktop.conf, which works without problems. This required a suitable module in rsyncd.conf on the desktop and to have the rsyncd service running on it when doing any emerging on the server.
Phew. Anyway, what used to take days is now measured in hours, so notwithstanding its lack of cores and MHz, my little home server continues to keep backups, share files and stream music around the house. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54893
Location: 56N 3W
|
| Posted: Wed Feb 19, 2025 10:48 am Post subject: |
|
|
greyspoke,
I use NFS vers=3 to 'sync' across systems and a bind mount into chroots.
That way I get identical repos, distfiles and binpackages where they are needed.
NFS is not secure, so only use it over a trusted network or over a secure tunnel.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
greyspoke
Apprentice
Joined: 08 Jan 2010
Posts: 175
|
| Posted: Wed Feb 19, 2025 4:51 pm Post subject: |
|
|
| Yes I think that's the way Neddy. I am aware of the security implications, but I don't think it is an issue on out home network. |
|
| Back to top |
|
|
|
|
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
|
|
Portage & Programming
