I came up with a good way to make distcc cross-compiling Just Work(TM) without running multiple distccd's and put together a guide on how to set it up. It's still a little rough and needs to be guidexml-ified, but the method works well.
(In reply to comment #0) > I came up with a good way to make distcc cross-compiling Just Work(TM) without > running multiple distccd's and put together a guide on how to set it up. It's > still a little rough and needs to be guidexml-ified, but the method works well. > Sweet. I'll start XMLifying it, and will attach it to this bug. :)
CCing lisa, author of distcc guide.
Created attachment 75458 [details] cross-compiling-distcc.xml Okay, here's the first draft of this document. It's fairly substantial, but agaffney did mention to me the possibility of adding it to the existing distcc guide. However, after XMLifying it, I really lean toward this being a separate guide, perhaps referenced from the distcc guide, as it currently wouldn't be easy to find a spot in that guide to integrate this one. Besides that distcc guide is outdated and needs to be changed anyway, especially when this guide is committed. :) Anyway, back to THIS bug and guide...what do you think?
Created attachment 75459 [details] cross-compiling-distcc.xml Corrected datestamp format (oops :) ), and clarified <abstract>.
Looks good to me. Is there somewhere this can be thrown so I can see it in "final" (rendered) form?
Created attachment 75463 [details] cross-compiling-distcc.html Okay, I followed the documentation tips 'n tricks doc to create this html page of the XML source. I know, the font sizes are likely to be messed up, but I just followed the guide to the letter. I think XML guides undergo a final step of transformation when viewed from gentoo.org. But this gives you a fairly decent idea of what it will look like.
Created attachment 75464 [details] cross-compiling-distcc.html Ack. Selecting the text/html content type in Bugzilla horribly, horribly messes up the rendering. I switched to "text/plain". I know it's a hassle, but just highlight all the text, save it as a .html file, and then open it up in your browser. Sorry about that; didn't know Bugzie messes up html files so badly.
(In reply to comment #7) > Created an attachment (id=75464) [edit] > cross-compiling-distcc.html > > Ack. Selecting the text/html content type in Bugzilla horribly, horribly messes > up the rendering. I switched to "text/plain". I know it's a hassle, but just > highlight all the text, save it as a .html file, and then open it up in your > browser. Sorry about that; didn't know Bugzie messes up html files so badly. > Never mind. I decided to upload it on my website: http://www.freewebs.com/nightmorph/docs/cross-compiling-distcc.html
It looks good, but I've got one thing that should probably be changed. "First, you will need to emerge crossdev on all the machines that will be involved in the compiling process." It's not necessary to emerge crossdev on all boxes involved. You only need crossdev on a box that will be helping via distcc that is *not* the same architecture as the box being helped.
Created attachment 75510 [details] cross-compiling-distcc.xml Okay, here's the requested revision.
Created attachment 75577 [details] cross-compiling-distcc.xml Corrected a couple of typos in the above revision. agaffney, any comments on the requested change? Everything look fine?
It looks good to me. Now that I think about it, we also need to note that that this cannot be used in conjunction with the CC=gcc method of "cross-compiling" between i[3456]86-pc-linux-gnu boxes. While it won't hurt anything, the compile will fail on the other end if the CHOST isn't the same, even though it's still x86. Users will need to either build an actual cross-compiler (i586-pc-linux-gnu cross-compiler on a i686-pc-linux-gnu box, for example) or create the proper symlinks. I don't know what symlinks need to be created, but I bet SpanKY does.
(In reply to comment #12) I think I understand what you're saying. In the interests of simplicity, it's probably better for users to actually build a full cross-toolchain in the desired CHOST (i[3456]86), rather than relying on symlinks. I'll see about finding a place to mention that differing CHOSTS on x86 require the specific cross-toolchain, at least when moving from higher arch to lower arch. (Obviously, i686 can run anything i386 produces). :)
Created attachment 76167 [details] cross-compiling-distcc.xml Here's the new addendum. I put it in its own subsection called "arch-specific notes"--> in the future, any additions to particular arches can be placed here. Sorry for the delay; I had thought that I was waiting to hear back from *you* until I rechecked the bug. ^_^
(In reply to comment #14) Also, so that you can view the current progress, I updated the version on my website, so you can preview the "finished" product by clicking here: http://www.freewebs.com/nightmorph/docs/cross-compiling-distcc.html
The sentence in the last paragraph about it checking argv[0] can probably be removed as it's unnecessary (yeah, yeah...I know that was my sentence :P). Vapier, what are your thoughts on this? I figured I should ask since you're basically Mr. Cross-compile.
only trouble i see is that it may not work for packages which need to compile & run a helper util natively ... for example, module-init-tools, e2fsprogs, ss, com_err, man, and ncurses to name some off the top of my head ... they'll prob try to invoke the native compiler as `gcc` and the cross compiler as `CHOST-gcc`
These programs would have trouble with *any* cross-distcc solution and really distcc in general then, wouldn't they?
no, why would they
If you have FEATURES="distcc" and a "vanilla" distcc setup, invoking `gcc` is just as likely to get you a distributed compile as `$CHOST-gcc`, cross-compiling or not. I'd say that a build that expects different behavior between `gcc` and `$CHOST-gcc` is broken. Anyway, what does it matter where a helper util is compiled? The (basically) same code will be generated and it's linked back on the first box.
not really ... autoconf packages tend to look for $CBUILD-gcc now though and it matters because the helper util is built & executed, but not installed
(In reply to comment #21) --> and all the above comments, actually :) So what, if any, changes and/or additions need to be made to the doc thus far? I've already removed the argv[0] reference, and will upload the new doc with any additional suggestions you have.
I just re-emerged and tested module-init-tools, e2fsprogs, man, and ncurses using this method to have my sparc help my amd64 box. Everything appears to work normally. What kind of problems might this method cause for those packages?
Something needs to be clarified in this guide. People keep getting confused and thinking they need to create these wrapper scripts on the helper boxes instead of the box running emerge. Any suggestions?
(In reply to comment #24) > Something needs to be clarified in this guide. People keep getting confused and > thinking they need to create these wrapper scripts on the helper boxes instead > of the box running emerge. Any suggestions? > Hmm, perhaps a note saying just that? Let me see what I can come up with. I think some explicit statements to this effect right around the "modifying distcc" code example would do nicely. :)
Created attachment 77445 [details] cross-compiling-distcc.xml Okay, I added a few clear notes about only performing the instructions on the box running the emerge. How does this look?
That's probably fine. After talking with Joker, there's a slightly easier/simpler method for doing this. Instead of multiple wrapper scripts, there can just be one called 'i686-pc-linux-gnu-wrapper' (or whatever CHOST): #!/bin/bash exec /usr/lib/distcc/bin/i686-pc-linux-gnu-${0##*/} "$@" Then you can just link cc, gcc, g++, and c++ to the single wrapper script. There is one slight problem, though. If 'cc' is called, it will try to call i686-pc-linux-gnu-cc which doesn't exist in that directory in a default distcc setup. They will need to create that symlink as well. That's as simple as: cd /usr/lib/distcc/bin ln -s /usr/bin/distcc i686-pc-linux-gnu-cc We were also trying to figure out a way to have the wrapper script determine the CHOST automatically so that one generic wrapper script would automatically work on all arches, but there's no real portable way to do it quickly.
(In reply to comment #27) > That's probably fine. > > After talking with Joker, there's a slightly easier/simpler method for doing > this. Instead of multiple wrapper scripts, there can just be one called > 'i686-pc-linux-gnu-wrapper' (or whatever CHOST): > > #!/bin/bash > > exec /usr/lib/distcc/bin/i686-pc-linux-gnu-${0##*/} "$@" > > Then you can just link cc, gcc, g++, and c++ to the single wrapper script. > There is one slight problem, though. If 'cc' is called, it will try to call > i686-pc-linux-gnu-cc which doesn't exist in that directory in a default distcc > setup. They will need to create that symlink as well. That's as simple as: > > cd /usr/lib/distcc/bin > ln -s /usr/bin/distcc i686-pc-linux-gnu-cc > > We were also trying to figure out a way to have the wrapper script determine > the CHOST automatically so that one generic wrapper script would automatically > work on all arches, but there's no real portable way to do it quickly. > K, I'll come up with an alt version of the guide that replaces the multiple scripts with a single script, and has the symlinks all point to a single...well, what would the individual g++ cc and so on point to?
They would link to the new "unified" wrapper script: ln -s i686-pc-linux-gnu-wrapper gcc ln -s i686-pc-linux-gnu-wrapper cc ln -s i686-pc-linux-gnu-wrapper g++ ln -s i686-pc-linux-gnu-wrapper c++
Please read bug 84942, which basically implements this script change. Just waiting on Pyrania.
(In reply to comment #29) > They would link to the new "unified" wrapper script: > > ln -s i686-pc-linux-gnu-wrapper gcc > ln -s i686-pc-linux-gnu-wrapper cc > ln -s i686-pc-linux-gnu-wrapper g++ > ln -s i686-pc-linux-gnu-wrapper c++ > Arggh, "midair collision" with Lisa while attempting to post. :p Okay, so what would the final ln -s look like after making this change? I assume that the code sample needs to be updated. I'm using the sparc CHOST in the rest of the instructions, as that's what's been used so far. So instead of creating multiple scripts and saving as gcc, g++, etc., we create on script named ${CHOST}-wrapper (sparc, i686, whatever) and symlink it to gcc, cc, g++, and c++, right? That's how my current version looks so far.
(In reply to comment #30) > Please read bug 84942, which basically implements this script change. Just > waiting on Pyrania. The patch in that bug was written by me :) I wrote this guide in case that patch doesn't become the default (since it breaks things for CC=cc i[3456]86 "cross" compiling people), or if it just takes a while to hit the tree.
Here's the full "new" procedure: kirara ~ # cd /usr/lib/distcc/bin kirara bin # ls c++ g++ i686-pc-linux-gnu-c++ i686-pc-linux-gnu-gcc cc gcc i686-pc-linux-gnu-g++ kirara bin # rm c++ cc g++ gcc kirara bin # cat > i686-pc-linux-gnu-wrapper #!/bin/bash exec /usr/lib/distcc/bin/i686-pc-linux-gnu-${0##*/} "$@" kirara bin # chmod a+x i686-pc-linux-gnu-wrapper kirara bin # ln -s /usr/bin/distcc i686-pc-linux-gnu-cc (only necessary if link doesn't already exist) kirara bin # ln -s i686-pc-linux-gnu-wrapper gcc kirara bin # ln -s i686-pc-linux-gnu-wrapper cc kirara bin # ln -s i686-pc-linux-gnu-wrapper c++ kirara bin # ln -s i686-pc-linux-gnu-wrapper g++ kirara bin # ls -l total 4 lrwxrwxrwx 1 root root 25 Jan 18 14:20 c++ -> i686-pc-linux-gnu-wrapper lrwxrwxrwx 1 root root 25 Jan 18 14:20 cc -> i686-pc-linux-gnu-wrapper lrwxrwxrwx 1 root root 25 Jan 18 14:20 g++ -> i686-pc-linux-gnu-wrapper lrwxrwxrwx 1 root root 25 Jan 18 14:20 gcc -> i686-pc-linux-gnu-wrapper lrwxrwxrwx 1 root root 15 Nov 21 10:42 i686-pc-linux-gnu-c++ -> /usr/bin/distcc lrwxrwxrwx 1 root root 15 Jan 18 14:20 i686-pc-linux-gnu-cc -> /usr/bin/distcc lrwxrwxrwx 1 root root 15 Nov 21 10:42 i686-pc-linux-gnu-g++ -> /usr/bin/distcc lrwxrwxrwx 1 root root 15 Jul 27 10:52 i686-pc-linux-gnu-gcc -> /usr/bin/distcc -rwxr-xr-x 1 root root 70 Jan 18 14:20 i686-pc-linux-gnu-wrapper
Created attachment 77858 [details] cross-compiling-distcc.xml Okay, here's the revised guide. Please check to make sure that the sparc toolchain names and symlinks are all valid, as I continued using the sparc examples from the original guide. Sparc is much sexier than i686, anyway. :p
You left out the part about creating the sparc-unknown-linux-gnu-cc -> /usr/bin/distcc symlink since distcc doesn't do it by default. Other than that, it looks good.
Created attachment 77859 [details] cross-compiling-distcc.xml Whoops, so I did. Fixed!
Spiffy. Now, what will it take to get this guide in as an official doc?
(In reply to comment #37) > Spiffy. Now, what will it take to get this guide in as an official doc? > Final version viewable at http://www.freewebs.com/nightmorph/docs/cross-compiling-distcc.html
(In reply to comment #37) > Spiffy. Now, what will it take to get this guide in as an official doc? /me will add it
Created attachment 77871 [details] cross-compiling-distcc.xml Fixed prompts.
In CVS. Thanks to everyone for their contribution.
After playing around with a patch to catalyst to implement this automatically, I've discovered a few "problems". I've got a slightly new procedure that seems to address them. cd /usr/lib/distcc/bin rm cc gcc g++ c++ cat > sparc-unknown-linux-gnu-wrapper #!/bin/bash exec /usr/lib/distcc/bin/sparc-unknown-linux-gnu-g${0:$[-2]} "$@" ^D chmod a+x /usr/lib/distcc/bin/sparc-unknown-linux-gnu-wrapper ln -s sparc-unknown-linux-gnu-wrapper cc ln -s sparc-unknown-linux-gnu-wrapper gcc ln -s sparc-unknown-linux-gnu-wrapper g++ ln -s sparc-unknown-linux-gnu-wrapper c++ Basically, the only changes are the contents of the wrapper script and not making the $CHOST-cc -> /usr/bin/distcc symlink.
Created attachment 78032 [details, diff] cross-compiling-distcc.xml.diff
Aside from one small issue (no need to specify full path to $CHOST-wrapper when chmod'ing it since you're already in /usr/lib/distcc/bin/), the patch looks fine. Can someone commit?
Done.
