* Patrick Palka: > On Fri, 4 Nov 2022, Florian Weimer wrote: > >> * Patrick Palka via Gcc-patches: >> >> > This patch moves the global object for constructing the standard streams >> > out from <iostream> and into the compiled library on targets that support >> > the init_priority attribute. This means that <iostream> no longer >> > introduces a separate global constructor in each TU that includes it. >> > >> > We can do this only if the init_priority attribute is supported because >> > we need to force that the stream initialization runs first before any >> > user-defined global initializer in programs that that use a static >> > libstdc++.a. >> >> I think this breaks initialization of iostreams of shared objects that >> are preloaded with LD_PRELOAD. With the constructor, they initialize >> iostreams once they are loaded via their own ELF constructors (even >> before libstdc++'s ELF constructors run). Without the constructor in >> <iostream>, that no longer happens. > > IIUC wouldn't that shared object depend on libstdc++.so and hence > libstdc++'s constructors would still run before the shared object's?
Hmm, right, we only reorder the symbol binding order, not the initialization order. The preloaded object will not participate in a cycle with libstdc++, so I think this should indeed be a safe change. Thanks, Florian
