On Sun, May 21, 2006 at 10:49:03PM +0100, Ken Moffat wrote: > For as long as I can remember, the multilib builds I've been doing > (x86_64 and ppc64) produce an appalling number of failures in the > 32-bit glibc tests, starting with some sort of problem with > de_DE.UTF-8 text in catgets, and then going rapidly downhill. > > The 64-bit multilib test results are reasonably clean, as are the > corresponding tests for i686 and ppc. > Status update: I couldn't find anything different in the 'program' files (.o.d and .o.dt) beond where the glibc include files were coming from (/tools/lib or /tools/lib64) and the specific include files that I looked at for the catgets tests are identical.
The resulting tst-catgets binaries are different (one is four bytes longer than the other, and the text at the end is accordingly offset by four bytes, but I couldn't make sense of the disassemblies - function addresses were different, as if random, and there are different offsets for some of the op-codes (I don't grok ppc assembler beyond the easy things like b and eieio). The data files, typically created by using sed on constant data, are identical. Looking at the first failure (catgets/de/libc.cat) there are four stages - 1. compile tst-catgets.c to tst-catgets.o with about 1600 characters of args, defines, and includes (i.e. about 16 lines of my 100-column xterm). 2. use gcc to link it into tst-catgets, with about 900 characters of args. 3. use sed in C locale to create the de.msg file. 4. run mkinstalldirs to mkdir /wherever/glibc-build/catgets/de. 5. with LC_ALL=de_DE.ISO-8859-1 and LOCPATH GCONV_PATH run the compiled elf/ld.so.1 with a very long --library-path and other args of de/libc.cat de.msg (which is where the multilib version barfs on umlauted characters). I've run these lines of my logs through a script to split the individual words off each line, then diffed the results - the only difference is that on multilib each invocation of gcc is accompanied by -m32. What I found interesting is that NLSPATH is defined as various attempts based on /usr/share/locale/ (%L/%N %L/LC_MESSAGES/%N, %l/N, %l/LC_MESSAGES/%N) - as a neophyte to i18n, I would expect that characters outside the C locale might be rejected in all builds because /usr/share/locales should be empty when we build glibc - but -m64 and non-multilib pass the test. So, I'm starting to suspect that on multilib we might be missing something for the 32-bit gcc that we build for the temporary system, or else something for the 32-bit cross-glibc. I suppose my next step will be to rebuild 32-bit glibc at the end of the completed system (i.e. using the final gcc). Or perhaps we should just forget about running tests and trying to prove the goodness of our builds ? Ken -- das eine Mal als Tragödie, das andere Mal als Farce _______________________________________________ Clfs-dev mailing list [email protected] http://ninja.linux-phreak.biz/mailman/listinfo/clfs-dev
