Well, maybe - I'm not actually an expert on object files. Never looked into how that works t.b.h.

The VASM manual says that some types of relocation don't work under KS 1.3, but I don't know when these are created (as in, I do understand when relocations are created, just not why the linker would choose one type over another). Perhaps it'll shed some light on the matter?

Quote:

Originally Posted by VASM Manual

‘-kick1hunks’

Use only those hunk types and external reference types which have been valid at the time of Kickstart 1.x for compatibility with old assembler sources and old linkers. For example: no longer differentiate between absolute and relative references. In executables it will prevent the assembler from using 16-bit relocation offsets in hunks and rejects 32-bit PC-relative relocations.

Look at the binary, does it start with $03f3 ? That is the header block id for executables (load files), whereas $03e7 is the header block id for linkable files. I would be really surprised if the loader on KS 1.3 accepted anything but the former.

EDIT: disregard - I mis-read roondar's reply and thought the problem was with -Fhunkexe.

When the program still assembles without error using -kick1hunks, then it cannot be an OS2+ specific relocation which was in use. So I am quite sure that the first executable just contained a HUNK_RELOC32SHORT hunk with 16-bit offsets for relocations, which is unknown to Kickstart 1.x, and which is the default without -kick1hunks (because it saves much space).

That the problem didn't appear with Bomb Jack might have several reasons. Maybe the sections offsets were too big for HUNK_RELOC32SHORT, or there were too many, or none at all? Or you linked the final executable from multiple object files with a different linker or different options?