Thanks Markus; I'll do that. On Fri, Mar 18, 2016 at 4:07 AM, Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx> wrote: > 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 -- Matt
