Hi Alexander, At 2025-08-25T20:32:23+0300, Alexander Monakov wrote: > On Mon, 25 Aug 2025, G. Branden Robinson via Gcc-help wrote: > > [please keep the groff@gnu list CCed; I am not subscribed to > > gcc-help] [...] > > https://savannah.gnu.org/bugs/?64421 [...] > > If anyone with relevant expertise is interested, I'd like to request > > a review of said ticket and solicit: > > > > 1. suggestions for a corrected/improved explanation of the fault; > > and > > 2. a ruling in or out of a toolchain defect I should have filed > > a bug about 2 years ago. [...] > Most likely you are hitting Static Initialization Order Fiasco: > https://en.cppreference.com/w/cpp/language/siof.html [...] > Since libgroff is a static library, the order in which constructors > run without LTO depends on the order in which linker extracts the > object files from libgroff.a static archive when linking. If the > dependencies are such that symbol.o is consistently pulled in prior to > color.o, the constructor for default_symbol would always run first. [...] > Oh, sorry, looks like it's worse: you were relying on the fiasco to > get default_color.nm initialized to all-zeroes instead of > default_symbol?
Thanks for shedding light on this! It sounds like, historically, we have been practicing such reliance. (groff's been through a few maintainers/lead developers in its 35+ years.) I'd have been proud to have captured a bug in LTO, but ashamed to have sat on it for two years. It's better to have made our code more robust. Regards, Branden
signature.asc
Description: PGP signature
