Peter N Lewis wrote:
At 23:10 +0100 26/3/03, Frank Heckenbach wrote:
Peter N Lewis wrote:
gpc -I/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces -funit-path=/Users/peter/unix/gpc/gpc-pinterfaces/GPCPInterfaces --automake -o testrecord testrecord.pas
it would automatically include all the necessary units, but apparently not (did this change, I think it worked before but I might have compiled it slightly differently).
This should work. Since you don't say what happens, I can't tell more.
/usr/local/bin/ld: Undefined symbols: _init_Adsp _init_Aedatamodel _init_Aehelpers
I figured it out:
- Units without `implementation' part
I have removed the implementation keyword after seeing that comment in the release notes (since they are all interfaces and have no implementation and the keyword is not needed on the Mac in this case). But it appears if this is removed, then the init routine is not included in the .o file even though it appears still to be needed when you import the file:
With no implementation keyword:
No calls to implicit_module_constructor or implicit_module_destructor calls are made which generates the necessary hidden functions used for a unit/module's initialization and finalization code. Those calls are necessary for the implictly created chain of calls that are generated by uses and imports.
After adding the implementation keyword:
And calls to implicit_module_constructor or implicit_module_destructor calls are made so the necessary hidden functions are created.
Is the keyword needed then, or is this a bug?
It looks like a bug to me.
Frank, I believe the problem is in the optional_unit_implementation production in the empty alternative. I think just adding implicit_module_constructor and implicit_module_destructor functions calls in the code block containing the "CHK_DIALECT" macro would fix the problem.
A larger issue, though, is why are "pure" interface units (and modules) included in the initialization and finialization call chains. By pure, I mean they are strictly interface declarations for external code which isn't going to be in the Pascal language initialization and finalization context. These are what ISO 10206 would refer to as an externaal interface. Paragraph 6.1.5, Interface-directives has a note which covers this:
"NOTE --- A processor may provide, as an extension, the interface-directive external, which is used to specify that the module-block corresponding to the module-heading containing the interface-directive is in some form other than an Extended Pascal module-block (e.g., it is implemented in some other language). When providing such an extension, a processor should enforce the rules of Extended Pascal pertaining to type compatibility."
The Mac OS X interface units Peter and others are working on is exactly the case the note is describing. There are no corresponding Pascal module-block or unit-implemenation-part for the interfaces.
Based on quick look, I think you should be able to handle purely external interfaces in the same manner as the standard interfaces are handled in creation of the call chain from import/uses. If an import/uses of a purely external interface is encountered, just skip adding it to the intializer chain which would eliminate the necessity for generating the hidden functions for "pure" external interfaces.
Gale Paeper gpaeper@empirenet.com