testing uClibc patch

Carl Miller chaz@energoncube.net
Thu Jan 8 01:00:00 GMT 2004

Whoa, lots of traffic on this topic, and right as I'm trying to wade
through the "just got back from vacation" inundation at work....

On Tue, Jan 06, 2004 at 03:23:02AM +0000, libber wrote:
> Ok sorry for the confusion from my last post, I do in fact have
> the relocate perl script I just forgot to delete that point before
> I sent. Also I think its much more likley that I am incorrectly
> applying your patches or something as opposed to your patches
> being wrong, so I was wondering, can you successfully build a
> mipsel-uclibc cross compiler with your patches applied?
> Firstly I should ask what is the correct way to apply patches
> for uclibc? I made a directory called 'uClibc-0.9.23' and put
> the patches in there but they seem to have not been applied,
> I am now building agian after copying that directory to 'uclibc-0.9.23'
> after noticing everything else in patches was in lower case.

You can either apply the patches manually after downloading and
untarring the source outside of crosstool, or you can place the
patches in a new directory called patches/uClibc-0.9.23 in the
crosstool tree before doing anything.  But if you're using crosstool
in a manner by which it only downloads each source tarball once,
then uses the existing source on subsequent runs, and the patches
weren't in place under patches/uClibc-0.9.23 before the first run
which did the download, then they won't have been applied, and
you'll have to apply them manually.

> The other thing I realized is that uclibc config
> prompts me for only one option during the crosstools build (should
> this happen? me being prompted for uclibc config options that
> is) which is something like add locale support or something.

Well, I couldn't test with every possible uClibc configuration, so
there are probably a few of these still lurking.  What's happening
here is that there are some uClibc options that must always be on
in order to make a usable C++ compiler.  If crosstool sees that
you're not building C only, it munges your uClibc configuration to
force those options on.  However, there are several cases in which
if option A was on but B was off, and crosstool forces B on, a new
option C appears which wasn't visible with A&&!B, and the
configuration system doesn't know how you want it set.  So it stops
to ask you.  I found and accounted for as many of those cases as I
could, and explicitly folded them into crosstool, but I knew that
given the number of configuration options in uClibc and the amount
of time I spent testing, odds were extremely slim that I got them
all.  What was the exact option that it stopped to ask you about?

> Secondly I have applied your patchesbut I still die on the same
> error as before even with having two copies of the directories
> as stated above.
> "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:115:
> error: cannot convert `const __ctype_touplow_t*' to `const int*'
> in assignment"

And that's even with the uclibc-glibc-version-features.patch applied?

If so, that's highly odd.  Do:

grep __GLIBC_MINOR__ uClibc-0.9.23/include/features.h

If you see only one line where that macro gets defined (to 2), then
that patch hasn't been applied -- apply it and see if that fixes
your problem.  If you see two lines where that macro gets defined
(once to 2 and once to 3), then you have already applied the patch,
and I'm not sure what's going on.  If this is the case, send me your
uClibc .config and I'll try to figure it out.  As as interim
workaround, try turning off extended locale support in your uClibc


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