On Wed, Jan 21, 2015 at 09:59:17PM +0000, Ken Moffat wrote: (changing the subject line, now that I have a little understanding)
> On Wed, Jan 21, 2015 at 10:43:55PM +0100, Pierre Labastie wrote: > > Hi, > > > > I have eventually found the time to build and test texlive on a 32 bit VM. > > Well, both tests for xindy pas: the index page is built and displayed (using > > either epdfview or mupdf). > > LFS SVN-20141225 > > Current BLFS > > > > I know it is not very helpful, but what else could I say? > > Oh yes, I know what to say. Ken did a magnificent job! > > > > <embarrassed>Thanks for testing it, and for the fixes along the > way. I would have done a better job if it did not fail for _me_ ;-) > > Must be something odd in my build (it also fails for me in a 32-bit > VM). > Minor correction - it _only_ failed for me in a 32-bit VM, I did not build it on the system which normally runs 32-bit, I used the binary there. And now: long story short - the problem is texmf-dist/xindy/modules/tex/inputenc/latin.xdy and my build method. A good version contains a header, two blank lines, and then a lot of lines containing lisp merge-rule commands, one per line (in parentheses) to convert TeX markup sequences to a character string. A bad version contains only the header, one blank line, and then: Binary file (standard input) matches Looking at the log, latin.xdy is created via perl scripts to create tex files which are then processed to create many .xdy files. And eventually make runs: echo ';; Generated from latin?.xdy' >latin.xdy iconv -t UTF-8 -f ISO8859-1 latin1.xdy >latin1-utf8.xdy echo >>latin.xdy iconv -t UTF-8 -f ISO8859-2 latin2.xdy >latin2-utf8.xdy sort -u latin?.xdy | grep -v '^;' >>latin.xdy Interestingly, the -utf8 files look fine, as do the latin?.xdy files (I reran the build by hand). I am not exactly sure which system I built separate 64-bit xindy on, so I tried running my script for separate xindy (2.5.1) on the 64-bit system I am currently using - and got the same breakage :-( The inputs to 'sort' look ok, at least in vim, but are apparently inconsistent. If I change LC_ALL from en_GB.UTF-8 to C, the build works. What I do not understand is why my two-pass builds from texlive worked on x86_64 but not on i686. For xindy-2.5.1 it is possible that something changed (or, at very long odds, maybe something in perl), but now that I understand the problem I'm off to ensure that all my scripts export LC_ALL=C. The problem is during the build, so a user building as themself in a UTF-8 locale need tso do this. I guess that jhalfs builds using the 'C' locale ? Do we have a preferred form of words for telling people that they need to do that ? e.g. mention it in the note, somehow save LC_ALL if different, set LC_ALL, build, restore ? And is POSIX the same as 'C' for LC_ALL, and if so, do we prefer that ? ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
