https://sourceware.org/bugzilla/show_bug.cgi?id=21705
--- Comment #2 from Mick Pearson <mick.pearson at wildblue dot net> --- (In reply to Alan Modra from comment #1) > Reports about 2.25 here are generally not interesting unless the problem can > be recreated with current master or release branch binutils. I recommend > that you try building a current linker to see whether the problem has > already been fixed. > > I also recommend that you run the last link command line by hand outside of > Eclipse. ld does not output anything after it has been killed.. What you > are seeing is the effect of buffering in your IDE. > > My guess is that ld is encountering an enormous number of linker errors, > your IDE can't cope, and possibly ld indeed is running into bugs in recovery > from earlier errors. Well, this seems more than user error to me. I was hoping someone will recognize the pathology at work. The behavior is the same on the command-line, output wise. It seems as though all of the output is backed up until the job finishes; and then appears all at once. It gives no indication of progress. I think that it was needed to use ((dllexport)) and ((dllimport)) attributes especially for Cygwin, but it doesn't change that the libraries I've compiled according to ld almost have an "undefined reference" to everything! (There must be an explanation.) Consider this: ../rt/libcolladadomRT2.5-sp.a(CrtRender.cpp.o):CrtRender.cpp:(.rdata$.refptr._ZN12ColladaDOM_32RT2Up4Y_UPE[.refptr._ZN12ColladaDOM_32RT2Up4Y_UPE]+0x0): undefined reference to `ColladaDOM_3::RT::Up::Y_UP' Y_UP is a static const compile-time expression. Yes, it's probably passed by address to a template that does not require its address, but if it's defined in this static library, then why would it be an undefined reference? And why would the static library not be linked together already by virtue of existing and already having gone through the link step? It's as if the static library is an archive of object files and nothing more? Or maybe that's why they are called "a" files and archives? In any case, how can it believe that something defined inside itself is an undefined reference? It seems to me like everything that is inline/static does not have a local definition in the translation-units. Normally if a static/inline something appears in a translation-unit (ODR) it is part of that object file, and the duplicates if any are discarded. It's as if that part of the objects where the definitions should live have been ripped out. I'm just trying to make sense. I think the mbig-obj file is working; but that ld is spending so much time generating undefined-reference errors that it can't do what would otherwise be very expedient. Is it possible the "undefined reference" exist but in a different format than ld expects? -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils