On Sunday, 18 February 2024 11:48:12 PST Jason McKesson via Std-Proposals
wrote:
> I would argue that the standard understands just fine what a library
> is. To the standard, a library is just a bunch of translation units,
> and that effectively models the behavior of static linking.

Fair, but one of the things that I see keep getting asked is the ability to
have symbols shared only inside of a library, but not outside of it. With
static linking, the notional binary module (which I'll just call "module" from
now on, because it's what the term originally meant before C++ repurposed the
term for something different) is the amalgamation of the static libraries and
non-library objects that get linked together.

In the majority of cases I've seen, a static library is actually a single unit
that just happens to be bundled together and would indeed like to share symbls
only inside of itself, not outside. We do see that in Qt, for example, where
we enforce that any function or class name that isn't static or inside of an
unnamed namespace must start with the letter Q or be in a namespace that does
that. This is to avoid "leaking" and "polluting" the namespace when the
libraries get linked together.

But there's a small minority (from experience) that are actually components of
a larger whole and would like to share symbols among themselves. This is often
an artefact of the buildsystem's inability to deal with the conditions, such
as files in a subdirectory (old Automake) or the limitations on command-line
length.

Either way, that's a toolchain problem and can be solved there. I haven't seen
much impetus to do it, but it could happen.

> The problem is dynamic libraries. A dynamic library acts like a bunch
> of TUs... except for when it doesn't. A dynamic library acts like a
> separate program... except for when it doesn't. And then there's the
> loading and unloading part, where a thing may or may not exist based
> on runtime behavior. There isn't anything in the standard that comes
> close to modelling the behavior of dynamic linking.
>
> Of course, there's also the fact that the two major implementations of
> dynamic linking don't exactly agree on all of the details.

Indeed and this is what I was getting at. They have a distinct behaviour from
that of TUs and that of whole programs that should be understood in the
standard. There are differences in behaviour between the major implementations
that make some things nasty, but the vast majority of common cases are
actually common and solved. We can standardise existing practice.

At a minimum, I'd say we need a standardised spelling for exporting and
importing symbols across dynamic library boundaries. We have two different
syntaxes for this and they get mostly hidden by macros these days, so solving
this would allow for common code and remove one more use of macros. Done
right, it would allow the grouping inside static libraries and static library
groups too.

That would also allow us to standardise whether using the address of an
imported symbol is a constant expression or not (it isn't on Windows), and the
discussion on load and destruction order too.

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