On Sun, Jul 23, 2006 at 11:26:24PM -0700, go moko wrote: > --- Ken Moffat <[EMAIL PROTECTED]> wrote: (quoting go moko's earlier mail) > > > > 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).
I'd got to the end of chapter 10 on ppc64, and you caught me before I was ready to set it up to boot the new system, so I've been able to slot in a couple of configure-make-check runs for 32-bit glibc (first run as in the book, to show that the errors exist even after installing system locales, second with your sed). The errors (only - from 'grep Error') are at the moment in http://www.linuxfromscratch.org/~ken/testresults/ppc64-glibc-results/ - to say I'm impressed with the difference would be an understatement! On 32-bit ppc64 I don't have any problems with c++-types-check, but on 64-bit I do, (included that log for comparison). I can now see that there is one real failure in my 32-bit tests in elf/check-textrel whatever that might be. Seems to me that this sed of yours fixes most of the glibc test problems! So, it ought to go in the book in my opinion. > > > 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? > I'm now almost certain this is a bash problem, because it has to do with a '(...)' subshell which sounds a bit like some of the parsing bugs seen early in bash-3.1, and because it seems to be ok on certain architectures, as if the data being passed through changes bash's behaviour. Also, that bug you referenced is from a clfs user, which suggests nobody else is seeing it. The part of scripts/check-c++-types.sh in question is data=$1 shift cxx="$*" while read t; do echo -n "$t:" $cxx -S -xc++ -o - -D_GNU_SOURCE <(cat <<EOF #include <sys/types.h> #include <sys/stat.h> #include <sys/resource.h> #include <unistd.h> void foo ($t) { } EOF ) | sed 's/[[:space:]]*[.]globa\?l[[:space:]]*_Z3foo\([_[:alnum:]]*\).*/\1/p;d' done <<EOF | - the error is triggered by '<(cat <<EOF'. I don't understand it all, but putting a here document into the compile from a substring ought to be legitimate. It gets called with the name of a data file containing values for the arch (this is diffed against the results at the end of the script) then g++ -O2 -I/something -I/somethingelse (lots of these) -D_LIBC_REENTRANT -include include/libc-symbols.h >filename Some quick experimentation suggests it needs to be called as it is when the test is run, referencing all the include files generated during the build of glibc, so it won't be practical to test this in isolation. Ken -- das eine Mal als Tragödie, das andere Mal als Farce _______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
