https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
Bug ID: 108261
Summary: modula-2 module registration process seems to fail
with shared libraries.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
After fixing PR108259 so that linking against the shared libm2* libraries
works, a simple Hello World bow fails thus:
$ ./hm
/src-local/gcc-master-patched/libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/RTentity.mod:244:in
findChildAndParent has caused internal runtime error, RTentity is either
corrupt or the module storage has not been initialized yet
Examining the libm2iso and libm2pim libraries, both seem to contain M2RTS which
seems to be a problem - since presumably only one instance of the module
registration system is workable ..?
.. likewise there are other duplicated modules.
... IIUC, the intention is that the link order should determine which SYSTEM.
definition is picked up ..?
... this all seems very fragile to me (except in the static linking case) ... I
wonder if the solution is:
* to combine the target libraries into one
* to make the SYSTEM spec something that the FE emits into the primary object
based on the various flags (so that it does not exist in the target library at
all)
* now we have all the CTORs run from startup . this means that every module in
the shared libraries will be registered (whether it is used or not).
-- perhaps the M2_link() would be better in the end so:
* remove the __attribute__((constructor)) / DECL_STATIC_CONSTRUCTOR() from the
_xctors
* call the M2_link() function to get them registered (in arbitrary order) and
then the dependency tree will only be operating on actual used modules?
NOTE: I am guessing to some extent about the intent of various mechanisms here
..
