https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #5 from Tom Kacvinsky <tkacvins at gmail dot com> --- I've conflated things. The issues of building binutils 2.34 and 2.35 on MinGW-w64 is a separate issue (perhaps an issue the MInGW-w64 folks know about and could help solve my build problems without hacks). I now have 2.34 and 2.35 building. As a starting point, I built our product with binutils 2.30 and GCC 121.1.0. This build was successful in the sense the application did not crash on start. Then, I bisected between 2.31 and 2.37 and found the break happened at 2.36. I scripted the steps gnatdll would use to make a DLL, then just changed which version of binutils I used in that script. At 2.36, I saw a break - a way around it is to use --disable-reloc-section. I just wanted to clarify the breakage happens at 2.36 and the other issues were not germane. An interesting observation the the --base-file output between 2.35 and 2.36 with --disable-reloc-section do not differ when using cmp -s. The .exp disassembles via objdump -Da (it's a PE image) to differ in one two byte sequence. objdump -p (relocation information) on the DLLs shows there is minimal difference (just timestamp and checksum, etc...) and most importantly, the relocations were exactly the same. So that's a +1. However, when using 2.36 without --disable-reloc-section, the base files fail a binary comparison to 2.35 (they should be the same, as they're to carry relocation offsets written out by cofflink.c). The exp files also disassemble with a multitude of differences (again, looking at differences of objdump -Da output with diff -u). The dump of the DLLs relocation tables obtained by objdump -p also show a multitude of differences - mostly relocations. So yeah, definite difference between 2.35 and 2.36 with relocation handling. -- You are receiving this mail because: You are on the CC list for the bug.
