[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 #6 from Mick Pearson <mick.pearson at wildblue dot net> ---
/bin/ranlib: libcolladadom3D-big-obj.a(viewer_base.lite.cpp.o): warning: COMDAT
symbol
'.rdata$_ZTVN12ColladaDOM_34DAEP9ElementalINS_9Collada0825__cg_param_group__float__ENS0_7ElementEEE'
does not match section name
'.xdata$_ZN12ColladaDOM_39Collada0526__cg_param_type__half1x4__D0Ev'

I don't know if this is at the root of my problems or not; but I've been
through a lot with my unique circumstances.

I thought that GCC's strictures are instantiating vtables were my most likely
issue. I could not think of a foolproof way around them, and I could not find
precise documentation, so I started by using the preprocessor to generate a
single CPP file, so I could be sure GCC would emit everything.

I've had to play around with that, until I believe the linker finished with all
of the inputs one time, but the components were not finding the virtual
methods. They seemed to want the method itself instead of a vtable. (They were
in a position to not use the vtable.)

So I rebuilt to try to externalize the virtual methods they wanted. And now I
get this error. 

It looks like a bug. The two names are completely mismatched. This is not when
linking the executable, but simply when building this object or putting it into
a single object archive (The archive isn't really necessary, but I am right now
leaving nothing to chance until everything works.)

P.S. Unless the one time things worked it was a fluke because of a hollow
archive or something, I think what really made the linker go forever was a
template class that had a static method with a local-static object inside of
it. It's not really a situation where every variation can be enumerated so I
changed it to a global static procedure local to the translation-unit.

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