[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 #5 from Mick Pearson <mick.pearson at wildblue dot net> ---
EDITED: I solved the truly confusing problems by moving the main (shared
library) in the link order to be behind the executable components.

(I think the GNU community would be wise to circle the linker back if doesn't
find a reference in the regular order.)

I had thought about the relationship of the executable's components in this
regard based on some things I read but I had not factored the core library into
those considerations. 

The biggest trouble I'm having now is that the big .o file defines the vtables
of classes that the component .a files use. I tried both moving the .o to after
the .a and copying it so it's before -o and after the .a without success...

I suppose either there is a special option for this, or to satisfy GNU/ld it
must be artificially packaged as a .a file.

There is absolutely no harm in ld looking in every .o and .a if it can't find
what it's looking for in the historical order. Microsoft's linker does so, and
it seems to me like order should only be important in edge case; that you're
not doing anyone any favor like this (I certainly don't appreciate the extra
effort I must make and losing a day's work contemplating this.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.