On 2016.03.17 at 23:15 -0500, Matt Godbolt wrote: > I've just spent a good few hours trying to reproduce, with no success. > I've also tried tracing the symbol with "-y" in both my (attempted) > repro case and the error case. > > In the repro case, the ~function() is not even generated with LTO: it > seems the trivial destructor is inlined in all cases. The non-LTO copy > is generated and is the one that's linked with. (I'm using -O3 for LTO > objects and -O0 for non-LTO like my error case has). > > In the error case, the symbol is defined in two places: > out/haswell/main/SystemExit.o: definition of _ZNSt8functionIFvvEED1Ev > lib/libseasocks.a(Server.cpp.o): definition of _ZNSt8functionIFvvEED1Ev > > std::function<void()> is used all over the code; so I suspect the > "SystemExit.o" file is just the place the LTO decided to generate it. > That said; I could only find references to the symbol in any of the > -save-temps *ltrans.*.s files. There's a " .set > _ZNSt8functionIFvvEED1Ev,_ZNSt8functionIFvvEED2Ev" in that file; > c++filt demangles the latter as the same as the former; and the latter > *is* defined. I wonder if this apparent "rename" (or whatever .set is) > is confusing the linker further on. That said; the "1" and "2" version > are both seemingly present in the library (libseasocks.a) too (as a > weak reference, according to nm). > > I really wish I could reproduce this! I'm posting this follow-up just > in case anything I've done or seen above jogs someone's memory or if > anyone has any further thoughts on what the root cause may be. I think at this point you should just open a gold bug and post your analysis there, because the gold maintainer probably doesn't read the gcc-help ML. -- Markus
