Re: ff-load problem

[Gary Byers <gb@cambridge.apple.com>]

    I just got my MCL 2.0 beta expecting that I could ff-load code
    compiled with MPW 3.2, but apparently there are problems.  I get the
    following error message:

    > Error: Unknown Object File version (3) in #<INPUT CCL::BINARY-FILE-STREAM
     to "HDinternal:NGL:color6.c.o">
    > While executing: CCL::FF-READOBJ

    If I try to continue, it finds an Unknown opcode.  My code is compiled
    for use of 68881, if that makes a difference.  I tried this first with
    a library file rather than an object file, and got the same results.
    I am not sure what "version (3)" is, but I would guess that is any MPW
    3.x object file.  So do I need to go back to MPW 2.x?  If so, I would
    also need to go back to system 6.0.x and that would be a shame since I
    need system 7.0 for other things.  Is there a workaround?

The "version 3" means that the file was compiled with symbolic debugging
information ("-sym on", if I remember correctly.)   There were bugs in
FF-LOAD in 2.0b1 that would cause it to a) not recognize this convention
and b) get out of synch when processing symbolic debugging records (hence
the "unrecognized opcode" error.)

These bugs are fixed in a set of patches available via anonymous FTP from
"cambridge.apple.com:~ftp/pub/MCL2/patches/".  There are release notes
which explain how to apply the patches; unfortunately, they fail to mention
that it's necessary to call (REINDEX-INTERFACES) after changing the
contents of some files in the "interfaces" directory.

If I remember correctly, object file version 1 was used in MPW 1.x and 2.x;
version 2 was introduced in MPW 3.0.  Version 3 is just version 2 with
symbolic debugging information; I'm not sure exactly when it got introduced.
(I wasn't paying attention, obviously.)

On a related note:  I don't think that the FFI passes floating point arguments
in the format that MPW C expects when the C code was compiled with hardware
floating point support (-mc68881) enabled.  You might want to see if you
can first get things working (without -mc68881), then see whether it's
possible to coerce arguments and return values between SANE's extended format
and the chip's.

-------