I've recently been using the new version of crossdev to build various cross-compilers on a few of my systems. I previously used separate distcc daemons with each cross-compiler with crossdev-0.4. I'm now using just one distcc daemon. I'm running into the problem of ebuilds just calling 'gcc' instead of 'i686-pc-linux-gnu'. '/usr/lib/distcc/bin/gcc' ends up getting called which passes 'gcc' as the compiler to the remote distcc server. The native (non-x86 in this case) compiler gets used on the remote distcc server. What I've done is remove the /usr/lib/distcc/bin/gcc symlink and replace it with a simple wrapper script: #!/bin/bash /usr/lib/distcc/bin/i686-pc-linux-gnu-gcc "$@" This causes 'gcc' calls to be distributed and cross-compiled correctly (afaict) by distcc since the /usr/bin/distcc only sees 'i686-pc-linux-gnu-gcc'. I can't see how this would cause problems in a non-cross-compiling distcc environment, so why not setup up distcc this way by default (wrapper script instead of symlink for gcc/cc)?
should be 'exec /usr/lib/distcc/bin/i686-pc-linux-gnu-gcc "$@"'
Other than that, is there any reason this can't be put in by default until all ebuilds are modified to call the full name of the compiler?
Calling the full name of the compiler has broken distcc for one of the groups that it has the most benefit for: A disadvantage of this it has broken distcc for those who have a slow, older system and want to use a newer system to speed up the compiles. Ie, a i586 host calls out to a i686 system to compile and it fails. This is wrong from my readings of the distcc docs as its only the compiler versions that matter, not the options (which are supplied correctly in any case). Also, this is a relatively new change and distcc has worked fine in this i586/i686 scenario up until these changes. According to numerous posts to the forums, the fix is to add CC=gcc and CXX=g++ to make.conf. I presume this bypasses numerous pieces of the way gcc/distcc is set up on gentoo, but it does work and distcc can again be used - but I think a proper fix should be made to either put distcc back to the way it used to be, or do the fix in suxh a way that it doesnt break distcc for the group that it has the greatest benefit for. Added the comment here, but a number of other bugs appear related to this. BillK
distcc hasnt changed, the rest of the toolchain has, and those changes arent being reverted the i[3456]86 issue has been mentioned before in other bugs but the only 'real' solution is an annoying one, name installing i[3456]86 symlinks on all x86 users' boxes although now with the new gcc-config's support of FAKE_TARGETS, we could probably graft on some stuff like i did with binutils-config ... then users would run `gcc-config --x86` and gcc-config would pollute the user's PATH with the extra i[3456]86 symlinks
Perhaps it would make more sense to wildcard or regex the [3456] in the identifier? I agree the the bin-utils and symlinks solutions suck - something simple and non-complex is needed as its a simple problem. A number of people seem to have gone the CC/CXX approach so who knows what that has broken - this seems to to be storing up future grief. This appears to have caused problems for quite a few people, + bugs, + posts to forums so there seems to be more userland interest in fixing this than cross-compiling which seems to have been the trigger for the changes for which I only stumbled over a couple of bugs requesting? Or is distcc just a casualty of the whole cross-platform push? Note I am not suggesting backing off the changes, but refactoring them to work properly. As this appears to be too complex for someone outside the toolchain group to suggest a fix, who do I hassel to see they are interested in taking it on? BillK
This is a nice workaround, but for simplicity the one specified in the Distcc Guide (CXX=gcc, CC=gcc) is the simplist. And besides, what about systems that have multiple toolchains? This workaround won't workaround anything for them.
Reopening after talking to lisa via IRC.
Created attachment 73313 [details, diff] patch to sys-devel/distcc-config to fix syntax errors and create wrapper scripts
You may want to remove the part of my patch that creates the wrapper scripts. I've put together a doc (bug 116575) that tells how someone can create these wrapper scripts themselves. Since my wrappers break CC=cc i[3456] "cross" compiling, it's probably best if the user creates these wrappers manually.
There is more or less a solution to this problem: Build-SLAVE: If you set the DISTCCD_PATH variable the distccd daemon will only look in the specified directory for compiler commands it accepts. Lets call the directory /usr/lib/distcc/accept. Now put a symlink for every compiler u want to use (native, cross compilers) and possible translations(eg. i386-pc-linux-gnu-gcc-3.4.4 -> /usr/bin/i686-pc-linux-gnu-gcc-3.4.6) in there. Build-HOST: If you then modify your wrapper script to call explicitly the compiler it wants. eg i386-pc-gnu-linux-gcc-3.4.4, if the slave has a matching symlink the compile will work. Possible TODOs: every new compiler install should probably put a symlink in the accept directory, maybe distcc USE flag?, gcc-config should modify the wrapper script and set the correct system compiler, modify /etc/init.d/distccd and /etc/conf.d/distccd/ to accept DISTCCD_PATH, ask upstream to make DISTCCD_PATH accept multiple directories
Since I often compile things on an amd64 machine for an i686 system (via distcc) I run into the problem that "gcc" is called instead of "i686-pc-linux-gnu-gcc" fairly often. Is this considered a bug in the corresponding ebuilds and/or shall this be reported for each ebuild seperately? is there bug (I didn't find) which sums it up?
Created attachment 175762 [details, diff] distcc-cross-compile I modified the ebuild to add a cross-compile use flag which installs the wrapper script and makes the correct symlinks. I do amd64 -> x86 cross compiles, so I don't worry about the i[456]86 problems, so this won't work for those people.
(In reply to comment #12) > Created an attachment (id=175762) [edit] > distcc-cross-compile > > I modified the ebuild to add a cross-compile use flag which installs the > wrapper script and makes the correct symlinks. I do amd64 -> x86 cross > compiles, so I don't worry about the i[456]86 problems, so this won't work for > those people. > any chance to have theese patches committed to portage tree?
Created attachment 187056 [details, diff] distcc-3.0-r4-cross-compile.patch Readapted Russell Harmon's patch to suite distcc-3.0-r4 that is the last stable version in portage for all arches.
(In reply to comment #14) > Created an attachment (id=187056) [edit] > distcc-3.0-r4-cross-compile.patch > > Readapted Russell Harmon's patch to suite distcc-3.0-r4 that is the last stable > version in portage for all arches. > I tried Russell's patch on distcc-3.0-r4.ebuild but it fails (since this patch is for 3.1 ebuild) so I modified manually the ebuild to suite Russell's changes. I choose 3.0-r4 because it is the last stable version on all arches. I hope this is useful to someone. Tested on i686 without a problem.
Created attachment 191343 [details, diff] distcc-3.1-r4.ebuild cross-compile patch cross-compile patch adapted to suite 3.1-r4 ebuild in the tree (last stable version for amd64/x86)
I re-adapted Russell's patch for 3.1-r4 . Any chance to get this patch in the tree?
I have created a modified version of the original wrapper script that _should_ work on all platforms. Let me know what you think. /usr/lib/distcc/bin/gcc-wrapper: #!/bin/bash if [[ "${0##*\/}" != "gcc-wrapper" ]] then CMDNAME=$0 else CMDNAME=gcc fi CHOST=${CHOST:-$(portageq envvar CHOST)} CHOST=${CHOST:-$(gcc -v 2>&1 |sed '/^Target:/ {s/^Target: // ; p} ; d;')} exec /usr/lib/distcc/bin/${CHOST}-g${CMDNAME:$[-2]} "$@"
I think it would be a neat idea to have a cross-compile USE flag for distcc that automatically sets this up. I can't help wondering if you have looked at the Gentoo guide on this, though? http://www.gentoo.org/doc/en/cross-compiling-distcc.xml These wrappers that you're writing seem to be reinventing the wheel, or do they have some subtly different purpose?
I have not only different CHOSTS, but also different system gcc versions in my setup. So here is my awkward wheel https://github.com/divanorama/divan-overlay/blob/master/sys-devel/distcc/files/wrapper It translates gcc calls to CHOST-gcc-1.2.3, also cc calls to CHOST-gcc-1.2.3 calls, CHOST and version are parsed from system/unwrapped/argv[0] compiler -v. Couldn't test it yet because something is terribly broken in building cross-compiler via crossdev (will file a separate bug when I'll investigate it enough).
distcc-3.2_rc1(masked) in cvs. I added crossdev to local USE flag. I also added new options (--update-masquerade, --update-masquerade-with-crossdev) to distcc-config. Please execute `distcc-config --update-masquerade-with-crossdev` if you add/update/remove crossdev target.
The latest wrapper works well when mixing various versions of gcc and targets. I have 3 different arm platforms here. Flucard Armv5 TS7260 amrv4tl Raspberry pi armv6 Works so far so good, thanks for the consideration.
Presuming fixed.