public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug modula2/108261] New: modula-2 module registration process seems to fail with shared libraries.
Date: Sun, 01 Jan 2023 17:14:00 +0000 [thread overview]
Message-ID: <bug-108261-4@http.gcc.gnu.org/bugzilla/> (raw)
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
..
next reply other threads:[~2023-01-01 17:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-01 17:14 iains at gcc dot gnu.org [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-108261-4@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).