Combining .o files?
frank at g-n-u.de
Thu Mar 27 12:50:25 CET 2003
Gale Paeper wrote:
> 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.
Indeed. (Our mails just crossed each other. :-)
> 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."
Well, it "may provide", but doesn't have to. ;-) In my experience
it's often useful to have a lot of external declarations and some
Pascal ones, e.g. to make some interfaces easier to use from Pascal
or add some functionality. Examples of this are the GMP and RegEx
units that come with GPC, the two Pascal units in the GRX library,
or the MySQL unit by Eike Lange.
> 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.
Perhaps it will turn out useful to add some. :-)
> 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.
It might be possible in this case (though not in cases where
`implementation' is given, but no explicit initializer since there
are problems with circulare references). You'll have to check
whether the unit uses any other units with intializers or contains
auto-initialized variables (because then it does need an
If you (or someone else) wants to do it, just go ahead. I have more
important things to work on (since this is neither a bug, nor a
missing feature, only a (very minor) performance issue, it's very
low on my priorities) ...
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
More information about the Gpc