[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