[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 #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.