[Bug c++/105397] New: Cannot export module initializer symbols with `-fvisibility=hidden`

[Bug c++/105397] New: Cannot export module initializer symbols with `-fvisibility=hidden`

[bugzilla.gcc at me dot benboeckel.net]

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.

[Bug c++/105397] Cannot export module initializer symbols with `-fvisibility=hidden`

[redbeard0531 at gmail dot com]

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?

[Bug c++/105397] C++ modules vs -fvisibility option

[bugzilla.gcc at me dot benboeckel.net]

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?

[Bug c++/105397] C++ modules vs -fvisibility option

[iains at gcc dot gnu.org]

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 [[...]];