--- Ken Moffat <[EMAIL PROTECTED]> wrote:
> In
> > conclusion, the problem is that the make doesn't
> > install the locale data if we are cross-compiling,
> and
> > so, the gencat test fails with the messages about
> > invalid characters.
> > A solution (perhaps there is better and nicer
> methods)
> > is to apply the following command before the "make
> -k
> > check":
> > sed -i '/cross-compiling/[EMAIL PROTECTED]@[EMAIL PROTECTED]'
> > ../glibc-2.4/localedata/Makefile
> >
>
> You are saying this fixes almost all the errors,
> even things like
> tst-strtod and stdio-common/bug14 ? I can believe
> that a lot of the
> errors are indeed locale related, but some of the
> test names (like
> these) sound a bit more general.
What I've seen is that the "make check" break on error
early without the sed, with messages about "Invalid
character" relatives to gencat on a deutsch message.
After the sed, the "make check" stop on one of the
last test, about a syntax error, as in 64 bits. I've
not seen any of the others errors you mentionned, but
I'm not in front of my machine, so I can't check that
these tests were good. I'll try to look and tell you
this evening (European time).
> In this context, cross-compiling must mean building
> for i686 on
> x86_64 ? I hadn't thought of the 32-bit compiles in
> multilib as
> cross-compiling.
Yes. From what I've seen, configure determines
cross-compiling by just comparing the triplets of the
machine and of the cible, which are different:
i686-unknown-pc-gnu for the cible (32 bits) and
x86_64-unknown-pc-gnu for the machine (in the
beginning of the output of configure).
> Also, to nit-pick, I hope "doesn't install the
> locale data" is
> "doesn't build the locale data" ? - I'll be even
> more worried if
> glibc is installing things in 'make' or 'make check'
> ;)
You're right, I misworded it. I mean: Install in its
own sub-directories. In fact, after the "make test",
if you make a "ls -l" on glibc-2.4/localedata, you'll
see that in 32 bits, there is just 3 empty files, but
in 64 bits, there's a lot of files. Moreover, in the
log of "make check", in 32 bits, you can see that the
"make --subdir=localedata tests" returns "Nothing to
be done" in 32 bits, but in 64 bits, it does a lot of
things, such as "installing" some locales for the
test. I've not tried to really install locales in 32
bits, as the CLFS book doesn't do it (localedef -I
de_DE...).
> > After that, the check run well, but fail on one of
> the
> > latest tests (also in 64 bits) on an error:
> > scripts/check-c++-types.sh: line 38: syntax error
> near
> > unexpected token '('.
> > I've looked at the shell check-c++-types.sh, and
> if I
> > can understand what it tries to check, I don't
> > understand the syntax, and bash don't like it
> either.
> > I've found this bug:
> >
> http://sourceware.org/bugzilla/show_bug.cgi?id=2930
> > about this problem, but there is still no
> solution.
> >
> > If someone can correct/patch this shell, or have
> any
> > solution, it would be very nice.
> >
> I wonder if that might be yet another problem in,
> or exposed by,
> bash-3.1 ?
I'm not expert of the shell, nor of bash, but this
syntax doesn't mean anything for me.
Does someone who build x86_64 multilib has the same
error in glibc check on 64 bits?
> Unfortunately, I've gone past glibc on ppc64 and I
> don't have time
> to look at it tonight. Thanks for the sed, it
> sounds very hopeful
> and it would be nice to get these errors fixed
> (although, yet again,
> this means that the errors are really in the
> testsuite).
It seems so.
G. Moko
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
