Re: Possible byte-order problems in TeX format files with -rc1

On Sun, 2 Feb 2003, Thomas Esser said:
>> I'm sharing format, pool and base files between a sparc64 (32-bit
>> userspace) box and an i386 box --- or I was; but between 20021225 and
>> -rc1, the byte-order independence of these files has broken, even
>> without NO_DUMP_SHARE; all .base, .fmt. .efmt and .mem files differ
>> between those platforms now.
> 
> Do you get error messages when trying to use a format file from platform
> x on platform y? If yes, can you provide a testcase for me?

Yes. Given this LaTeX testcase:

\documentclass{article}
\begin{document}
This is really minimal.
\end{document}

Format generated on sparc-unknown-linux-gnu, TeXing on i586-pc-linux-gnu:

This is TeXk, Version 3.14159 (Web2C 7.4.0)
 %&-line parsing enabled.
latex: fatal: Item 6 (=1192) of .fmt array at 81df168 <-268435455 or >1020.

Format generated on i586-pc-linux-gnu, TeXing on sparc-unknown-linux-gnu:

This is TeXk, Version 3.14159 (Web2C 7.4.4)
 %&-line parsing enabled.
latex: fatal: Item 0 (=52497348) of .fmt array at 1b0298 >4168.

Very similar problems happen with tex as well as latex (unsurprisingly);
the last number is slightly different, and that's all.

>> This could be due to the hanging instance of NO_FMTBASE_SHARE (which
>> should be NO_DUMP_SHARE) in config.h, but since I don't have 64-bit
> 
> That really looks like a bug.

Good to see that you agree. I've looked at the code and can't see
anything *really* obviously wrong (saving the NO_FMTBASE_SHARE
weirdness)...

> I have just successfully used a i366-linux generated format file
> (tex.fmt and latex.fmt) on a sparc-solaris. So, I don't see anything
> wrong...

I do, alas :(

-- 
2003-02-01: the day the STS died.