Hi, On Sun, May 14, 2023 at 2:44 PM Tom Kacvinsky wrote: > Hi NIck, > > On Wed, May 10, 2023 at 7:38 AM Nick Clifton wrote: > >> Hi Tom, >> >> > What I found through lots of experimentation is that either the base >> file >> > generated by ld or the exp file generated by dlltool is off and is >> making >> > a DLL that causes our applications to crash >> >> > The reason I say it's either the base file or the exp file is that I can >> > take my export definition file (a .def file) and generate an import >> library >> > and exp file using Microsoft's lib tool, and that exp file makes the >> final >> > link produce a DLL that does not have an issue. >> >> > I have a way around the problem without using a base file (just pass the >> > .def file directly to ld so that an export table is generated), but I >> > wanted to report this issue. >> >> Thank you for doing this. It always helps when problems are reported, >> even >> if we do not have a solution available. >> >> Please could you file a bug report here: >> >> https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils >> >> > I haven't yet done so as I am fighting getting at least the major versions > of > binutils between which things broke. I think that would help to have in > the > bug report. > > But it appears it is going to be more involved than I thought. I thought > I was > going to get away with building all of our code with one binutils (using > the > version of binutils I know works) and then just swapping versions of > binutils > used for making the DLL until I find the version that broke. But that > process > ends up producing a DLL Windows does not like. :-(. So, I have to build > the > entire GCC + binutils toolchain, with the binutils version changing and GCC > remaining fixed. This will take a while. > Filed bug https://sourceware.org/bugzilla/show_bug.cgi?id=30448 as I found the versions between which things broke. I think I even have a problematic commit. Regards, Tom