https://sourceware.org/bugzilla/show_bug.cgi?id=21705
--- Comment #4 from Mick Pearson <mick.pearson at wildblue dot net> --- Thanks Alan, I know this isn't exactly a help desk; but I hope there are others here who might help me. A problem I run into is almost all talk about "undefined reference" diagnostics devolves into, "you need to put the -lx options after the -o option." I can't really test the shared library that links to verify that it works. But I just find it funny that it builds and the executable does not, and has so many of these undefined reference diagnostics that should logically plague the shared library also, but don't. It's frustrating because everything is done by the book and the commands are right there to see, and it's all legit and even when I pull out the suspect large-object component I still see these "undefined reference" diagnostics pretty much for everything. I would think that ld is not finding the project's libraries but they are there in the output, as in the case of Y_UP. (Which might require an external definition under C++98; but -std=gnu++11 is used. And -O1 was used across the board in this build also.) I don't understand why this doesn't just work. If everyone has this kind of difficulty the GNU developer community must be tired of fielding calls for help :) -- 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
