testing uClibc patch

Carl Miller chaz@energoncube.net
Mon Jan 5 17:46:00 GMT 2004

> Hello I have been using the uClibc patchs to make a mipsel cc
> (for the linksys wrt54g in particular).
> 1) all patches work great except the patch to crosstools itself,
> a few hunks fail but they don't stop me from starting the build
> script and it getting pretty far. here is what i get in crosstool.sh.rej

Ah, I should probably have specified that this patch was on top of my
"common source" patch, which allows crosstool to pull from a unified
source tree shared by multiple projects.  It also will be happy finding
unpacked source, even if there's no tarball.  That was posted to the
list here:


I got rushed with the uClibc patch, and didn't make a separate version
for people who hadn't already applied the common source patch.  Sorry
about that.  But it looks like what you did should work just fine.

> 2) when it comes time to build uclibc there seems to be a problem.
> these are the lines i get
> "+ test '!' -f Makefile
> + uClibc-0.9.23/relocate
> /usr/local/crosstool-0.25/crosstool.sh: line 260: uClibc-0.9.23/relocate:
> No such file or directory
> Done.
> "
> and when I look at line 260 in the patch I see "${LIBC_DIR}/relocate".
> it seems from this (http://www.uclibc.org/lists/uclibc/2003-December/007747.html)
> that relocate is a perl script, could I have a copy? :)

Did you apply the patches to binutils, gcc, and uClibc given in this post?


The relocate script is added by the uclibc-makefiles.patch.

Also check that you have this one:


as some architectures require it.

I should really collect all that up into one clean package.  Dan, which
would you prefer, one big huge patch for crosstool that does everything
(but also touches everything, and thus might be a pain to integrate into
your source tree), or would you rather pick through what I've already
submitted and put it in piece by piece, figuring there will be fewer
merge conflicts that way?

> 3) in getandpatch.sh:151 the urls for uclibc are incorrect, they
> should be uclibc.org/downloads/old-releases/ instead of uclibc.org/downloads.

Whoa!  Thanks for pointing that out.  Yeah, apparently there have been
three releases of uClibc since I started working on this, and they've
already moved the version I started with out of the main download
directory.  Dang.

> 4) permissions for the relocate script, i needs to be chmodded
> +x around line 260 in crosstool.sh

Hmmmm, yeah, I might have to special case that patch to uClibc.  Does
anyone know if there's any way to tell patch that one particular new
file it's about to create should be created +x?  If so, I'll hand-edit
the patch to make it so.  If not, it'll have to be a special case in
getandpatch.sh, done after it applies the patch.

> 5) sed errors out with "Invalid reference \1 on `s' command's
> RHS" fix is to put \s before any (s which i learned from http://albatross.madduck.net/pipermail/debian-unizh/2003-August/000125.html
> so after doing all of those things and putting all the patches
> in patches/ I have the compile process fail when it gets to libstdc++
> in the gcc section. Here is the error:
> "In file included from /usr/local/crosstool-0.25/build/mipsel-unknown-linux-gnu/gcc-3.3.2-uClibc-0.9.23/gcc-3.3.2/libstdc++-v3/src/ctype.cc:36:
> /usr/local/crosstool-0.25/build/mipsel-unknown-linux-gnu/gcc-3.3.2-uClibc-0.9.23/build-gcc/mipsel-unknown-linux-gnu/libstdc++-v3/include/mipsel-unknown-linux-gnu/bits/ctype_noninline.h:
> In
>    constructor `std::ctype<char>::ctype(int*, const short unsigned
> int*, bool,
>    unsigned int)':
> /usr/local/crosstool-0.25/build/mipsel-unknown-linux-gnu/gcc-3.3.2-uClibc-0.9.23/build-gcc/mipsel-unknown-linux-gnu/libstdc++-v3/include/mipsel-unknown-linux-gnu/bits/ctype_noninline.h:84:
> error: cannot
>    convert `const __ctype_touplow_t*' to `const int*' in assignment

That's addressed by the uclibc-glibc-version-features.patch which can be
found here (same big batch of patches I referenced before):


> any advice or tips on how to continue past this error much appreciated.

How'd that do?

I'm out of the office today, and I've been for most of the past two weeks,
and all my uClibc and crosstool stuff is on a server I can't access from the
outside.  So hopefully the post-vacation inundation won't be too bad
tomorrow, and I'll be able to see about fixing the uClibc URLs and permissions
on relocate later this week.


Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com

More information about the crossgcc mailing list