Q: Why does my code not load into my image?
Problem
Scenario 1: Reference before Definition
Best practice is to define programming components like Smalltalk classes before referring to them. However, some applications become complicated enough that this is difficult to do.
If a method refers to a yet-to-be-defined class, loading it into your image may result in a warning that the yet-to-be-defined class is being defined as a global in unmanaged space.
Depending on how your image is configured, loading such a method can result in a warning or an error to the Transcript.
E.g. the referenced class may be defined as nil and a warning appears in the Transcript.
Warning: 91 Defined global CsEELargeUniqueIDGenerator in unmanaged namespace while loading UniqueGeneratorTest>>testDecodingNew.
Or, it may result in a compilation error:
compiler error "undefined"
--> CsEELargeUniqueIDGenerator manager
....
Error: 357 Cannot complete the load because UniqueGeneratorTest>>#testDecodingNew(2/14/2013 12:10:12 PM) does not compile.
NOTE: If you reload after executing:
EmImageBuilder cancelIfMethodsDoNotCompile: false
methods which do not compile will be deleted.
Failed trying to load Resolver(7/26/2019 10:58:01 AM)
Scenario 2: Bytecode cache loading issue when bitness changes
This scenario involves loading code which was developed in a VAST 32-bit environment into an image running in a VAST 64-bit environment. Again, the symptom is an error to the Transcript reporting a compiler error "undefined" error similar to that described in Scenario 1.
Consider the following situation:
•First, you develop code in 8.6.3 or earlier and export that code into a DAT file. This is guaranteed to be a 32-bit VAST.
•Later, you import your code from that DAT file into the code library from VAST 9.0 or later.
•You create a 64-bit VAST environment for VAST 9.0 or later, launch that image and load that code.
The result is a load failure and an error in the transcript.
Explanation
Importing into a code library does not result in recompilation of the compiled code, loading the code developed in 32-bit VAST into a 64-bit image, that will result in a recompilation. Recompilation implies the need for relinking, but the old bytecodes for referenced classes are cached in the image.
Solution
In scenario 1, one action could be to define your class before you refer to it.
Stopping the load if a method does not compile can help to identify methods that make a reference before the class is defined. Do this by executing the folowing Smalltalk expression in the Transcript or a workspace:
EmImageBuilder cancelIfMethodsDoNotCompile: false
If the symptom is that you get a compilation error, another action could be to turn off the linker.
Turning off the linker is done by EmMethodEdition useLinker: false.
In scenario 2, the proper action is to turn off the linker.
Last modified date: 01/12/2021