https://sourceware.org/bugzilla/show_bug.cgi?id=21705
Bug ID: 21705
Summary: ld disappears up own butt never to return (a curious
case?)
Product: binutils
Version: 2.25
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: mick.pearson at wildblue dot net
Target Milestone: ---
Created attachment 10240
--> https://sourceware.org/bugzilla/attachment.cgi?id=10240&action=edit
Two files. Output and dump (mostly repetitive text.)
That's an awful subject I know. I have an unusual program that is and isn't
linking.
The linker is not reporting errors. But it runs continuously with only about
150 to 300MB of memory, and I'm pretty sure it will do this until the end of
days.
That said, there's an executable that is approximately the same size as the one
Visual Studio builds. Inside it looks more like an object file though.
It is continuously changing. It's almost like ld is using it as a buffer to
hold onto its errors. This is on Cygwin. In Eclipse if I kill poor ld its death
rattle outputs some "undefined reference.". But it never sends these until it's
killed. If canceled via the IDE it also never terminates. And never outputs. It
just hangs.
There's an object that is built separately with -mbig-obj. ld behaves the same
if it's not built separately (it needs to not use the precompiled header) and
if it has the same compile options.
Everything said to be an "undefined reference" should be inside that object.
And the lines all refer to it. It could be that the compiler (g++) is handing
off a bad object. But it compiles it and reports errors accurately.
The program does unusual things. It converts XML schemas into generated
configuration files that create a heterogeneous container that acts like the
XML schemas. It's not just a tree, it interacts with C++, and I've rewritten it
to use templates to be very clever, but maybe too clever.
Some of the same constructs that say they are undefined references are built in
a shared library that is a "DOM" library. It links without issue. So it seems
to me like this is more a question of overload than correctness.
The references say the vtables are missing. But they are all pure-header based
tables. And they are all fully defined. The job of the big object file is to
localize the metadata registration routines to itself.
Versions of Visual Studio prior to 2015 were very bad at template heavy code,
but the 2015 edition can build the project very quickly, within a minute. So
there's no reason for ld to take more than say 15 minutes, much less forever.
It's C++98 code, and it builds fine on older Visual Studios. This week I've
been porting it to GCC. It passes all the way to the linker, and now I'm kind
of at my wits end. It might be more of a Cygwin thing or it might be something
that newer versions of ld than Cygwin's have already addressed.
Attached is the make VERBOSE=1 build commands (mostly they are the same) and
the final "dump" that appears when ld is killed. I don't think it does that on
a regular commandline. I should add that the "dump" will be different every
time, suggesting that it is working, but that maybe it's stuck in a rut. The
typeid stuff in it I fixed with -frtti and it just made those "errors" go away.
I can provide the full workspace if it looks interesting.
--
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
