public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/105397] New: Cannot export module initializer symbols with `-fvisibility=hidden`
@ 2022-04-26 17:46 bugzilla.gcc at me dot benboeckel.net
2022-06-09 13:47 ` [Bug c++/105397] " redbeard0531 at gmail dot com
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: bugzilla.gcc at me dot benboeckel.net @ 2022-04-26 17:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397
Bug ID: 105397
Summary: Cannot export module initializer symbols with
`-fvisibility=hidden`
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla.gcc at me dot benboeckel.net
Target Milestone: ---
There is no way to decorate an `export module X;` with an
`__attribute__((visibility("default")))` such that it ends up visible in the
resulting shared library if `-fvisibility=hidden` is passed. I also tried
linker scripts with no luck.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/105397] Cannot export module initializer symbols with `-fvisibility=hidden`
2022-04-26 17:46 [Bug c++/105397] New: Cannot export module initializer symbols with `-fvisibility=hidden` bugzilla.gcc at me dot benboeckel.net
@ 2022-06-09 13:47 ` redbeard0531 at gmail dot com
2022-12-08 20:43 ` [Bug c++/105397] C++ modules vs -fvisibility option bugzilla.gcc at me dot benboeckel.net
2022-12-21 11:32 ` iains at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: redbeard0531 at gmail dot com @ 2022-06-09 13:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397
Mathias Stearn <redbeard0531 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |redbeard0531 at gmail dot com
--- Comment #1 from Mathias Stearn <redbeard0531 at gmail dot com> ---
Perhaps the best option is to default the visibility of the implicit functions
to the widest visibility of any function or object in module purview exposed by
the TU. The assumption being that if anything is visibile outside the library,
then it is expected to be imported from TUs outside the library and that should
Just Work. Conversely, if everything is defined as internal visibility, then it
is unlikely that this module was intended to be imported from outside of the
library, and so it may be desireable to allow different libs to have their own
module with the same name.
Unfortunately that doesn't give any good indication of what to do for
importable units that have an empty module purview (or where everything inside
it has TU-local internal linkage). While legal, maybe that isn't a case worth
optimizing the Just Works experience for?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/105397] C++ modules vs -fvisibility option
2022-04-26 17:46 [Bug c++/105397] New: Cannot export module initializer symbols with `-fvisibility=hidden` bugzilla.gcc at me dot benboeckel.net
2022-06-09 13:47 ` [Bug c++/105397] " redbeard0531 at gmail dot com
@ 2022-12-08 20:43 ` bugzilla.gcc at me dot benboeckel.net
2022-12-21 11:32 ` iains at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: bugzilla.gcc at me dot benboeckel.net @ 2022-12-08 20:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397
--- Comment #2 from Ben Boeckel <bugzilla.gcc at me dot benboeckel.net> ---
> Perhaps the best option is to default the visibility of the implicit functions to the widest visibility of any function or object in module purview exposed by the TU.
What to do about `extern "C"` APIs made available by a module? Is that even
allowed? Imagine a library providing some C API by implementing in C++ modules;
should the module initializer be public API too?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug c++/105397] C++ modules vs -fvisibility option
2022-04-26 17:46 [Bug c++/105397] New: Cannot export module initializer symbols with `-fvisibility=hidden` bugzilla.gcc at me dot benboeckel.net
2022-06-09 13:47 ` [Bug c++/105397] " redbeard0531 at gmail dot com
2022-12-08 20:43 ` [Bug c++/105397] C++ modules vs -fvisibility option bugzilla.gcc at me dot benboeckel.net
@ 2022-12-21 11:32 ` iains at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: iains at gcc dot gnu.org @ 2022-12-21 11:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397
--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
the import places attributes at the end.
so
import module Foo [[....]];
it would seem to be symmetrical to have:
export import Foo [[...]];
export module Foo [[...]];
but, ts present, (if I read it correctly) it seems that the WD says
export [[...]] module Foo;
export [[...]] int bar ();
which would then be weird with export [[...]] import Foo [[...]];
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-12-21 11:32 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-26 17:46 [Bug c++/105397] New: Cannot export module initializer symbols with `-fvisibility=hidden` bugzilla.gcc at me dot benboeckel.net
2022-06-09 13:47 ` [Bug c++/105397] " redbeard0531 at gmail dot com
2022-12-08 20:43 ` [Bug c++/105397] C++ modules vs -fvisibility option bugzilla.gcc at me dot benboeckel.net
2022-12-21 11:32 ` iains 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).