[tex-live] tl7 final frontier

Thomas Esser te@informatik.uni-hannover.de
Sun, 26 May 2002 08:55:31 +0200


> I have not done anything about the long MacOSX or xdvi arguments;
> I trust that those involved sorted it all out. I am making
> alpha osf replacement binaries, as my sole contribution...

I have put up the fixes for xdvi into the source. Most platforms
have fixed binaries:

$ for i in */*xdvi.bin; do grep 22.40k $i >/dev/null 2>&1 && echo "good: $i" || echo "bad: $i"; done | sort
bad: i386-solaris2.8/oxdvi.bin
bad: i386-solaris2.8/xdvi.bin
bad: powerpc-aix4.3.3.0/oxdvi.bin
bad: powerpc-aix4.3.3.0/xdvi.bin
good: alpha-linux/oxdvi.bin
good: alpha-linux/xdvi.bin
good: alphaev5-osf4.0d/oxdvi.bin
good: alphaev5-osf4.0d/xdvi.bin
good: i386-linux/oxdvi.bin
good: i386-linux/xdvi.bin
good: mips-irix6.5/oxdvi.bin
good: mips-irix6.5/xdvi.bin
good: sparc-solaris2.7/oxdvi.bin
good: sparc-solaris2.7/xdvi.bin

Is there anybody who can contribute new binaries for i386-solaris2.8 /
powerpc-aix4.3.3.0?

Sebastian, can you try to trigger this?

I guess that any unfixed xdvi will immediately crash now (at least when
running from CD against the full set of configured type1 fonts):

    $ wc ps2pk.map 
       3867   21349  261081 ps2pk.map

    xdvik-22.40i, i.e. the version currently used in TL7, and `large'
     .map files (with more than 31 encodings or more than 3071 fonts -
    yes, it's an off-by-one-error) that will cause to a segmentation
    fault while reading the .map file(s) at startup time, independent
    of the current DVI file.

Thomas