public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug modula2/108261] New: modula-2 module registration process seems to fail with shared libraries.
@ 2023-01-01 17:14 iains at gcc dot gnu.org
  2023-01-01 17:16 ` [Bug modula2/108261] " iains at gcc dot gnu.org
                   ` (28 more replies)
  0 siblings, 29 replies; 30+ messages in thread
From: iains at gcc dot gnu.org @ 2023-01-01 17:14 UTC (permalink / raw)
  To: gcc-bugs

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
..

^ permalink raw reply	[flat|nested] 30+ messages in thread

end of thread, other threads:[~2023-02-27 13:34 UTC | newest]

Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-01 17:14 [Bug modula2/108261] New: modula-2 module registration process seems to fail with shared libraries iains at gcc dot gnu.org
2023-01-01 17:16 ` [Bug modula2/108261] " iains at gcc dot gnu.org
2023-01-01 17:24 ` iains at gcc dot gnu.org
2023-01-01 17:59 ` iains at gcc dot gnu.org
2023-01-02 13:39 ` iains at gcc dot gnu.org
2023-01-04 16:24 ` iains at gcc dot gnu.org
2023-01-05 21:10 ` iains at gcc dot gnu.org
2023-01-09 15:10 ` gaius at gcc dot gnu.org
2023-01-09 16:34 ` iains at gcc dot gnu.org
2023-01-09 22:34 ` gaius at gcc dot gnu.org
2023-01-10  0:01 ` iains at gcc dot gnu.org
2023-01-11  2:00 ` gaius at gcc dot gnu.org
2023-01-11  8:57 ` iains at gcc dot gnu.org
2023-01-11  9:42 ` iains at gcc dot gnu.org
2023-01-11  9:45 ` iains at gcc dot gnu.org
2023-01-11  9:55 ` iains at gcc dot gnu.org
2023-01-11 15:02 ` iains at gcc dot gnu.org
2023-01-11 15:07 ` gaius at gcc dot gnu.org
2023-01-11 15:22 ` gaius at gcc dot gnu.org
2023-01-11 21:10 ` iains at gcc dot gnu.org
2023-02-14 23:30 ` gaius at gcc dot gnu.org
2023-02-14 23:32 ` gaius at gcc dot gnu.org
2023-02-14 23:34 ` gaius at gcc dot gnu.org
2023-02-19 16:59 ` gaius at gcc dot gnu.org
2023-02-22  0:39 ` gaius at gcc dot gnu.org
2023-02-23  9:48 ` gaius at gcc dot gnu.org
2023-02-23 12:07 ` gaius at gcc dot gnu.org
2023-02-23 20:35 ` iains at gcc dot gnu.org
2023-02-25 16:29 ` cvs-commit at gcc dot gnu.org
2023-02-27 13:34 ` gaius at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).