[Bug ld/21705] ld disappears up own butt never to return (a curious case?)

[mick.pearson at wildblue dot net]

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.