This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> The crosstool goal is "less than 30 minutes of effort, or 3 minutes best > case". > YMMV. Well, arm soft-float issues are proving to be much more than that, but everything else seems (from my limited testing) to be well in hand now. > I'm really looking forward to the new uclibc support patches from Carl. Here they are! This is a single patch against crosstool-0.28-rc5. It includes the required patches to binutils, gcc, and uClibc by creating new files in the relevant patches/* subdirectories. Also newly created is gcc-3.3.3-uclibc-0.9.23.dat which should give you all the base defines to make a uClibc toolchain. Currently, the only versions supported are: binutils 2.14 or 2.14.90.0.5 gcc 3.3.3 uClibc 0.9.23 Supporting other tool versions is simply a matter of porting the patches over such that they install cleanly and do the right thing on the newer (or older) tool. Those of you who are chuckling at the blithe use of "simply" in that sentence are wise to do so; this is not a task for a beginner. I mean only that no further changes to crosstool itself should be required. I had hoped to port my Makefiles-relocate.patch for uClibc to 0.9.26, but as of tomorrow I'll no longer be paid to work on this, so no promises. I think at one point, Dan mentioned on list that these patches were meant to be "less invasive". Erm, well, no, they aren't. I was going for "more complete" and "more correct", rather than "less invasive", and as you might imagine, they don't meet the "less invasive" criterion all that well, at least as it pertains to crosstool itself. They're great about not altering binutils or gcc behavior unless you ask for a uclibc target, and I'd argue they're invasive in a good way to uClibc (but others will no doubt disagree). On the upside, I think I've addressed all the shortcomings that were voiced on list to my first set of uClibc-crosstool patches from December, and since then, the uClibc project has seen fit to make a hugely positive change in how they patch gcc and binutils. Consequently, I've dumped my original gcc-uclibc and binutils-uclibc patches in favor of those now provided by the uClibc project, which are more complete, better thought out, and will be better supported. Dan, let me know if there's anything you'd like me to adjust to make the changes to crosstool more palatable -- I know in places it's going to be uncomfortably hefty at first glance. Also, I haven't heard anything from Ted Teah about FSF assignment since I mailed off the employer disclaimer; let me know if there's anything else I need to do on that front and I'll get right on it. Enjoy! As always, feedback welcome. ------Carl
Attachment:
crosstool-uclibc-0.28-rc5.patch.gz
Description: Binary data
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |