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]

Re: crosstool uClibc patches


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]