[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: Re: ff-interface
- From: firstname.lastname@example.org (Sean Doyle)
- Date: Wed, 12 Apr 1995 09:11:07 -0400
- Sender: email@example.com
>When I load the C functions (ff-load) this error message appears:
>> Error: Offset #x-F492 too large to fit in a word
>> While executing: CCL::ADD-REF
>is It possible to solve this error ? How ?
Three are a number of different ways that this problem can be 'solved',
most of them with *only* an annoying level of pain. The problem is that
MCL's linker can only only address up to 32K byte offsets in a single ff
environment (ff-env). Usually the cause is one of the following:
1. You have large static data structures in your C routines that make it
impossible for the linker to address all of the offsets.
2. There are too many functions defined in your C routines... and the linker
simply ran out of room.
3. The linker links in everthing that it thinks that it needs... and it put
a lot of unreachable entry points (dead code) into your ff-env, so you
ran out of room linking in the real code.
Case #1 can be fixed by removing the large static data declarations in C
and replacing them with either NewPtr or malloc calls. If you need to load
in explicit initial values you can feed them in from Lisp.
Case #2 means that you need to define another ff-env with a second #'ff-load
command. This works, but there are two potential problems (that I've done
to myself... :-):
Problem a) The two ff-envs are completely separate addressing spaces. So, if
you call an initialization routine in one it has no effect on the
state of variables in another ff-env. So, if you have C routines
that have to share data structures that are not in the same ff-env
you need to pass pointers between them for shared structures.
If you don't do this, then MacsBug will be glad to stop your
program until it gets fixed.
Problem b) If you have common subroutine libraries, and you don't restrict
the entry points (described below), the linker may have linked in
one of your functions more than once. If your functions have
side effects in C, the function may get invoked in a different
ff-env than the one that you are expecting.
You need to remember to define the :ffenv-name keyword on your ff-load
statement so that each ff-env gets a unique name. Otherwise they simply
replace one another (I think). Another problem is that if you have many
ff-load environments that your compilation takes longer.
Case #3 can be fixed by the :entry-names keyword in ff-load. Make sure that
you specify only the routines that you want access to in MCL... this helps
the linker avoid linking in dead code. I think that the default in the
linker is to link in all of the entry points in all of the specified files.
One solution that won't work (yet) is that you can create MPW libriaries
with the "-far" option and it generates offsets that transcend the 32K
boundary. I don't think that this works in the current version of MCL, but
maybe in the future it will (if the software gods smile upon us).
Please let me know if this doesn't help.