https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124268
Ben Boeckel <bugzilla.gcc at me dot benboeckel.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|c++ |libstdc++
--- Comment #4 from Ben Boeckel <bugzilla.gcc at me dot benboeckel.net> ---
Full disclosure: I'm "the" CMake C++ modules guy :) .
So yes, the `std.o` file needs to be provided. However, I argue that it should
be part of `libstdc++.so` (or `.a`). Otherwise, we have ODR hazards when
project A builds its `std.o` and then B links A into its own libraries that
also need `std.o`. Not to mention which one "wins" when one project uses C++23
and another C++26; are the symbols different?
If `std.o` is deferred to the consuming executable, that is a very leaky
situation. Imagine I write a plugin for some program using C++ internally. The
rest of the program uses C. Do I bring in `std.o` in my plugin or expect it to
come from the C-only loading binary? If each plugin brings their own `std.o`,
what happens when two such plugins are loaded?
IMO, libraries should ship the module initializers for the modules they provide
just like any other symbol.
