https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #12 from Tom Kacvinsky <tkacvins at gmail dot com> --- (In reply to Eric Botcazou from comment #11) > > The problem is an access violation at startup, deep in the guts of the DLL > > loader. Doing a debug session with Visual Studio and looking at registers > > and memory locations, it was determined that loading the DLL in question is > > where things went south. > > For a DLL generated by GNAT? Which version of GNAT is that? GNAT that comes from GCC 12.1.0. I am using MSYS2 + MinGw-w64 for my base setup, then compile a custom GCC 12.1.0 with mingw-w64-crt v10.0.0 and binutils 2.38. This includes MinGW-w64's support for the UCRT, as we need that for the version of Visual Studio we also use to build out product. > > > And, for what it's worth, perhaps --disable-reloc-section is not a good name > > for an option - the DLL I produced with that option does have a .reloc > > section. So what exactly does --disable-reloc-section mean if specifying > > that option still results in a DLL with a .reloc section? > > So it generates a different .reloc section? Yes, binutils 2.35 generates a different .reloc section than binutils 2.36 (with default options) unless one uses binutils 2.36 with --disable-reloc-section. I shall gather what files I can attach that don't contains the proprietary binary code, just the relocation information. -- You are receiving this mail because: You are on the CC list for the bug.
