On Wednesday, 19 April 2023 15:38:25 PDT Frederick Virchanza Gotham via Std-
Proposals wrote:
> If we link dynamically with libspellcheck, the global variable
> 'status' won't be made available to us. However if we link statically,
> we can access all the global variables.

Because there's no *actual* difference between linking statically and compiling
those translation units into your project.

> Compilers have different ways of specifying that a variable/function
> is accessible from outside the library, for example -fvisibility or
> dllexport or --version-script. I don't know of any compiler though
> that has an option for making static libraries that says "make this
> symbol visible within the library but invisible outside the library".

Correct, because of the reason above.

> So overall this would give us three kinds of linkage:
>
> static int status; // not visible outside this translation unit
> extern int status; // visible everywhere
> intern int status; // visible to other translation units inside the
> library

This is impossible to implement right now because it's just not how linkers
work. You'd need to work with the implementations to first have a technical
solution, before even attempting to standardise.

It needs to take into account when static libraries are actually *not*
conceptually separate libraries. Depending on the buildsystem in use, it may
be necessary to collect the object files into static libraries before linking
them into the final binary, which may be a shared library.

Moreover, I'd expect there to be a need to have library groups too. On Darwin
(macOS, iOS) systems, a framework may be composed of multiple libraries and
they may want to share variables and functions amongst themselves, but not
expose to other frameworks. You may want to look at the Darwin-specific
extern_private keyword.

Finally, since the standard doesn't know what a library is, I seriously doubt
that this would become a standards solution. At best, you can reserve the
keyword and leave the details of how it actually works to the implementations.

This is all without saying the M word.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering