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] | |
This line in getandpatch.sh doesn't seem to be working
getUnpackAndPatch http://www.uclibc.org/downloads/$LIBC_DIR.tar.bz2 || \
getUnpackAndPatch http://www.uclibc.org/downloads/$LIBC_DIR.tar.gz || \
getUnpackAndPatch http://www.uclibc.org/downloads/old-releases/$LIBC_DIR.tar.bz2 || \
getUnpackAndPatch http://www.uclibc.org/downloads/old-releases/$LIBC_DIR.tar.gz
It's not trying the "old-releases" directory, and the subsequent unpacking
fails:
+ wget -P /amnt/john/home/mark/downloads -c
http://www.uclibc.org/downloads/uClibc-0.9.23.tar.bz2
--11:25:21-- http://www.uclibc.org/downloads/uClibc-0.9.23.tar.bz2
=> `/amnt/john/home/mark/downloads/uClibc-0.9.23.tar.bz2'
Resolving www.uclibc.org... done.
Connecting to www.uclibc.org[63.223.66.155]:80... connected.
HTTP request sent, awaiting response... 404 Not Found
11:25:22 ERROR 404: Not Found.
+ test -f /amnt/john/home/mark/downloads/uClibc-0.9.23.tar.bz2
+ abort 'file uClibc-0.9.23.tar.bz2 not found'
+ echo file uClibc-0.9.23.tar.bz2 not found
file uClibc-0.9.23.tar.bz2 not found
+ exec false
I moved the old-releases directory to the first part of the expression and
it worked.
Then, later I get:
.
.
.
+ '[' -d linux ']'
+ '[' -d kernel ']'
+ test -d
/amnt/john/home/mark/arm-dev/crosstool-0.28-rc5/patches/uClibc-0.9.23
+ cd uClibc-0.9.23
+ test -f
/amnt/john/home/mark/arm-dev/crosstool-0.28-rc5/patches/uClibc-0.9.23/Makefiles-relocate.patch
+ patch -g0 --fuzz=1 -p1 -f
+ cat patch26225.log
patching file Makefile
Hunk #7 FAILED at 258.
1 out of 10 hunks FAILED -- saving rejects to file Makefile.rej
patching file Rules.mak
which results in:
patching file utils/Makefile
+ abort 'patch /amnt/john/home/mark/arm-dev/crosstool-0.28-rc5/patches/uClibc-0.9.23/Makefiles-relocate.patch failed'
+ echo patch /amnt/john/home/mark/arm-dev/crosstool-0.28-rc5/patches/uClibc-0.9.23/Makefiles-relocate.patch failed
patch /amnt/john/home/mark/arm-dev/crosstool-0.28-rc5/patches/uClibc-0.9.23/Makefiles-relocate.patch failed
+ exec false
Mark
On Tue, Apr 20, 2004 at 06:53:02PM -0700, Carl Miller wrote:
> > 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
--
Mark Beckwith, Intrig (http://www.intrig.com)
------
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] |