https://sourceware.org/bugzilla/show_bug.cgi?id=30930
--- Comment #8 from Julian Sikorski <belegdol at gmail dot com> --- (In reply to Nick Clifton from comment #7) > (In reply to Julian Sikorski from comment #5) > > (In reply to Nick Clifton from comment #4) > > > You may find it useful to compare a broken-linked-with-ld.bfd binary > > > with a working-linked-with-lld binary. In particular the contents > > > of whatever init sections they have, and the ordering of function > > > pointers therein. > > > > I am downloading the broken binary from the test system now. How can I do > > the above? > > Well first you can compare the disassembly of the .init section to make sure > that it is the same in both binaries: > > objdump -D -j .init mame > > Next I was going to suggest that you check the contents of the .init_array > section but it appears to be all zeros, which is a bit strange. > > You could be paranoid and check that the hardware property notes are the > same on both binaries: > > readelf -n -W mame | grep -e .note.gnu.property -A 4 > > But I doubt if that show any discrepancies. > > But I suspect that the only real way you are going to get some traction on > this problem is if you bring in the glibc folks. Maybe file a bug report > telling them that mame is hanging during initialization and that you need > their help finding out where things have gone wrong ? Let them know about > the new version of binutils of course, but do ask them if they can track > down exactly what the linker has done wrong in order to cause the init code > to hang. How would I bring in help from glibc folks? Should I just reassign the bug to glibc? -- You are receiving this mail because: You are on the CC list for the bug.