Talk:Distcc/Cross-Compiling
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 08:29, 5 November 2024 (UTC) :: Your reply ~~~~
Possible FEATURES distcc-pump Requisite
Hello, looooots of happy computing hours since the last, unofficial, wiki was gone and yet more hours of good work was gone. Really, I'm still very sad and mad about that history. Can't really stop crying about the content we've made.
These times, Android rules so nothing aggresive to Mike Valstar who has lost mysql database.
.....ouch, to the topic:
FEATURES="distcc-pump" is necessary to make things happen. If there is no, some weird errors display, like:
distcc[7377] ERROR: failed to connect to UNIX-DOMAIN /tmp/distcc-pump.43wo4c/socket: Permission denied — The preceding unsigned comment was added by Januszzz (talk • contribs)
- Something doesn't appear correct with your DistCC installation then, as FEATURE=distcc is just the default DistCC process and should just work. FEATURE=distcc-pump additionally compiles preprocessor statements via DistCC, and is not needed for normal DistCC to work. — The preceding unsigned comment was added by Roger (talk • contribs)
- I believe you've misunderstood Januszzz's point. Using distcc-pump mode without the (now non-existent) distcc-pump feature causes the issue he described. Using plain distcc works fine. Same here on 3 brand new 17.1 installs. I've used it system-wide, thousands of packages literally for several years on several machines and architectures, zero issues, I think I'd know by now if it were the monster that some claim it to be. Of course I opt out on some packages via package.env. I understand if the devs feel nervous about it, but can't we leave the capability for those who want to use it? No, it's not needed, neither is distcc, perhaps we could all make do with monochrome monitors again too. But it makes a significant difference in compile times for me.Yuyu (talk) 00:04, 30 January 2020 (UTC)
This Cross Compiling via DistCC Wiki Mostly Deprecated?
I just setup a 32 bit (i686) cross compile environment on a 64 bit platform, using the basic instructions found at Gentoo Cross Development Guide (Gentoo Documentation Project) and Distcc/Cross-Compiling, and then setup the DistCC service and everything just appears to work. I'm thinking that the CHOST variable is now exported alongside the compilation job, and the server doing the compiling then picks-up this flag. (As DistCC should have from the start, to prevent compiling and then exporting the binary to a non-compatible platform!)
The only trivial parts:
- The Cross Compile Gentoo documents seem slightly out-dated, and carry far more instructions then really likely needed. A likely more simpler setup can be performed.
- Setting up DistCC locally and testing locally (ie. 127.0.0.1) is best. The Gentoo DistCC service failed to write the initial DistCC log due to improper permissions (ie. /var/log/distccd.log) Check /etc/groups and there's no distcc group, so just quickly did "touch /var/log/distccd.log && chmod a+rw /var/log/distccd.log" and then "tail -f /var/log/distccd.log" for monitoring DistCC for properly compilation. (Using tail is much easier than the distccmon* tools during initial setup.)
- Then I made sure my main 64-bit server was compiling, but setting-up DistCC and creating the log file as previously mentioned as well as starting tail on that log file.
- For kicks, figuring I was going to need some exotic stuff from this Wiki page, I decided to compile something simple to see if the binary would fail upon execution on the remote 32 bit i686 laptop (ie. app-misc/screen), but surprisingly screen works and the log files on the server show i686 being used during compilation!
distccd[20386] (dcc_job_summary) client: 192.168.1.4:50757 COMPILE_OK exit:0 sig:0 core:0 ret:0 time:1422ms i686-pc-linux-gnu-gcc screen.c
NOTE: I think the worse part is probably still remembering to use IP addresses and not host names! (ie. localhost2.local) Several years ago, I pulled out my hair for days trying to understand why DistCC was failing over this simple problem. This time setting up DistCC, I remembered I had to do something, and quickly scanned a manual page designating this step.
FOLLOW-UP: When upgrading or downgrading with multiple crossdev compilers installed, users need to make sure the correct crossdev compiler is selected on the DistCChost! (ie. gcc-config -l) --Roger (talk) 03:29, 30 April 2014 (UTC)
- This no longer seems to be an issue but please reopen if you think I'm wrong
- Immolo (talk) 01:34, 7 March 2023 (UTC)
Uninstalling old gcc versions
Not much documentation is available for instructing beginners how to uninstall old cross-compiled gcc versions or cross compiled tools.
I can only imagine something like:
- crossdev --clean i686-pc-linux-gnu-4.7.3
But this still leaves the profile within "gcc-config -l", as wells as the many "ie. /etc/portage/profile/package.use.force/cross-=i686-pc-linux-gnu-4.7.3" files! (Oh my, what a mess. Likely even I did something incorrectly. I wonder if the crossdev -g (etc.) version arguments has any effect. — The preceding unsigned comment was added by Roger (talk • contribs)
Re-organization of Documentation
I also think the documentation on this page (as well as many other crossdev related pages) needs some organization! The following page concerning "How to install & use distcc" far out performs instructing new users to install and use distcc. (If you're worried about any bias, just let the Google.com search engine show the following page's popularity!)
http://psas.pdx.edu/GentooCrossCompilerHowto/
The main confusion I think of this page, all advanced instructions (or additional scripting) should likely not be put alongside with the basic instructions especially due to the complicity of explaining DistCC configuration. The advanced instructions or additional scripting should likely be placed into a completely separate advanced section, so beginners are not further confused. Dunno, just my thoughts here as to what I would do. — The preceding unsigned comment was added by Roger (talk • contribs)
No mention how to update crossdev toolchain on the host(s)
There is no mention of how to update the cross-compiled tool chain on the host(s).
---Snip---
xaviermiller mentioned on Sun Oct 26, 2014 12:12 pm:
As I said, there are 2 modes for upgrade
- update the cross toolchain using the host system will be done by the host portage (cros-*/{binutils,gcc,gibc})
- update the target packages is done using by re-cross-compiling them, using cross-emerge (target-emerge)
---Snip---
Now if somebody wants to translate this from low-level CrossDev/Gentoo to English, it would be appreciated! (I think I already did below.)
Even upon system update on the host, "gcc-config -l" and "binutils-config -l" are still showing the crossdev tools to be not updated or not routinely updated. Seems the only sure method of updating the crossdev toolchain is to repeatedly manually uninstall & reinstall the crossdev toolchain weekly or often! (Of which installing or reinstalling crossdev toolchain is complicated and prone to errors.) --Roger (talk) 11:21, 4 October 2015 (UTC)
- Seems I may have something working here concerning the "Gentoo target-emerge" method mentioned by xaviermiller. First the HOST="" variable needs to be further defined prior to using the target-emerge command. (ie. # CHOST="i686-pc-linux-gnu" i686-pc-linux-gnu-4.8.3-emerge -uDNpv world) Further more the reason for not seeing the main toolchain updates, maybe the installed crossdev packages are not added to the world list for routine upgrading, or just manually updating the packages individually maybe required, as such target-emerge -uDNpv world doesn't show much at all as for upgrading. So, # CHOST="i686-pc-linux-gnu" i686-pc-linux-gnu-4.8.3-emerge -upv gcc", and perform the similar for the additional binutils, glibc, linux-headers packages required for cross compiling. One reassuring sign this appears correct, the pretend command states "[ebuild N ] sys-libs/glibc-2.21-r1:2.2::gentoo to /usr/i686-pc-linux-gnu/" on stdout, further showing changes or updates will be made to the root folder "/usr/i686-pc-linux-gnu/"! --Roger (talk) 11:37, 4 October 2015 (UTC)
- And using the crossdev method for updating: "crossdev -t i686-pc-linux-gnu --portage -u -p -v" Note, when using "--portage" flags, the flags need to be specified individually and will likely not be parsed correctly if the flags grouped together! (Sometimes need to further clarify each flag, "--portage -U --portage --deep --portage -p --portage -v") However, this method tends to miss packages such as GDB and may require using the "--ex-gdb" option, or is prone to not installing the latest stable version sometimes. On the flip, when specifying optional packages such as GDB, this method doesn't require setting the PYTHON version unlike the above Gentoo target-emerge method. --Roger (talk) 13:26, 4 October 2015 (UTC)
Configuring distcc to cross-compile correctly
I find no effect nor is crossdev mentioned in IUSE of any of the ebuilds in the tree as of 1-18-18. --Yuyu (talk) 02:12, 28 January 2018 (UTC)
Bell07 (talk) 14:25, 18 June 2019 (UTC)
Can anyone confirm the whole part "Configuring distcc to cross-compile correctly" is obsolete? The current distcc can handle the cross-compilation in default installation?
See distcc[5573] (dcc_gcc_rewrite_fqn) Re-writing call to 'gcc' to 'aarch64-unknown-linux-gnu-gcc' to support cross-compilation. in
# DISTCC_VERBOSE=1 distcc gcc test.c distcc[5573] (dcc_trace_version) distcc 3.3.2 aarch64-unknown-linux-gnu; built Jun 17 2019 08:52:46 distcc[5573] (dcc_recursion_safeguard) safeguard level=0 distcc[5573] (main) compiler name is "distcc" distcc[5573] (dcc_scan_args) scanning arguments: gcc test.c distcc[5573] (dcc_scan_args) found input file "test.c" distcc[5573] (dcc_scan_args) compiler apparently called not for compile distcc[5573] (dcc_gcc_rewrite_fqn) Re-writing call to 'gcc' to 'aarch64-unknown-linux-gnu-gcc' to support cross-compilation. distcc[5573] (dcc_get_hostlist) not reading /root/.distcc/hosts: No such file or directory distcc[5573] (dcc_parse_hosts_file) load hosts from /etc/distcc/hosts ...
- Replacing the compiler calls with the fully qualified name of the compiler is indeed natively supported by distcc since version 3.2. I've added a corresponding note to the start of the "Configuring distcc to cross-compile correctly" section.--Eruvaer (talk) 22:04, 19 February 2021 (UTC)
i686 crossdev on ~amd64 no longer works by fiat
Crossdev gives me this error and refuses to run:
root #crossdev -t i686-pc-linux-gnu -s4* Refusing to create a cross-compiler using the same * target name as your host utils. * Consider using sys-devel/multilib-gcc-wrapper package.
I installed the package it suggested and it seems to work with distcc (so I guess that's the new way to go), but I'm now lacking the ability to create i686 binpkgs using the cross-emerge wrapper. That would've really helped for things like gcc which don't distribute well. Ant P. (talk) 23:05, 20 March 2020 (UTC)
- This is by design as you don't need to setup a cross compiler for x86 on amd64
- Immolo (talk) 01:36, 7 March 2023 (UTC)
- But how does one setup /usr/i686-pc-linux-gnu/etc/portage/make.conf and all the correspondig layout to call i686-pc-linux-gnu-emerge in the end? But it's more related to Binary package guide actually.
- Moving this discussion there and closing this one as Distcc cross-compilation seems to be working fine with sys-devel/multilib-gcc-wrapper