It never occurred to me that some compiler might generate multiple THEADER/MODEND sets within a given OBJ module it spits out. Yet this seems to be exactly what one version of the Ryan/McFarland FORTRAN compiler does that I have. LINK apparently accepts this construct OK.
[UPDATE]
Even though ancient (and current) versions of the Microsoft LINK handle this multiple THEADER/MODEND construct, Borland's TLINK crashes and burns when it encounters it. TLINK apparently assumes an OBJ can have only a single THEADER/MODEND set and simply stops scanning the input file after the first one. Net result - lots of unresolved symbols and a failed link. The Borland TDUMP utility for dumping the contents of an OBJ seems to list multiples, but displays some bogus information due to internal variables not being reinitialized when it encounters a THEADER.
[UPDATE]
If its being spit out by compilers and accepted by LINK, then I'll need to handle it too.
[UPDATE]
It seems this moronic Ryan McFarland FORTRAN compiler is also emitting BOGUS checksums for certain OBJ record types. So far I've seen it happen on LNAMES, and LEDATA. The SEGDEF's looked OK though.
I know some language translators punt on the record checksum byte and just set it to zero, but this is the first I've seen plugging in garbage.
No comments:
Post a Comment