Thanks for the feedback. That nails it as the extension being at fault.
To save confusion, I'll use the term "library" instead of "extension", as all the AMOS instructions reside in libraries. The core ones come supplied, the extension libraries just add on to that. AMOS makes no distinction when it loads them. (Not quite true as the main AMOSPro.Lib does get some special attention, but it doesn't affect what happens with the rest.)
Many libraries make use of the "initialisation code" feature for libraries. Each library's "initialisation code" is run after the interpreter has loaded all registered libraries. ("Registered" just means that you've told the interpreter's config file what libraries to expect and what their library slot number is. Turbo is in slot 12. It's what you do in the editor when you add an extension library.) The code usually does things like allocating storage and initialising data.
That seems to be where it's failing. I don't know why the compiler should complain at that point unless it runs any initialisation code (which to me wouldn't make sense, but I haven't pulled the compiler apart yet so I may well be talking rubbish
). Another possibility is that the structure of the library is not quite correct and that's upsetting the compiler. It's interesting that it's only happening with this extension library loaded - it gives a nice clear-cut case of "It don't work - ever!" to look at.
With the Turbo extension library, from just a quick read through the docs, it also looks likely that it may be stepping outside the amos.library functions and data structures to do what it advertises. That may also cause a bit of strife with the compiler.
Oh well, that's probably not all that much use to you. It just reminds me how much work there is ahead when we finally get into cleaning up extensions! (After the bug-free and documented AMOS Pro V2.xx and the AGA AMOS Pro V3.xx projects are completed. So not next week then...
).