Hi again, > -----Original Message----- > From: Kacvinsky, Tom > Sent: Thursday, May 4, 2023 12:45 PM > To: mingw-w64-public@lists.sourceforge.net > Subject: RE: [Mingw-w64-public] Exported symbols of import .lib are > influenced by the .def file > > Hi Luca, > > > -----Original Message----- > > From: Luca Bacci <luca.bacci...@gmail.com> > > Sent: Thursday, May 4, 2023 11:38 AM > > To: mingw-w64-public@lists.sourceforge.net > > Subject: Re: [Mingw-w64-public] Exported symbols of import .lib are > > influenced by the .def file > > > > Thanks for the response, Tom! > > > > Yes, that would work, but we'd end up with decorated names in the > > export table fo the DLL. For some projects that's a problem, because > > there's no uniform way to call GetProcAddress. > > > > If I recall correctly, symbols that are decorated with @nnn use the stdcall > calling convention. Have you tried making them use the cdecl calling > convention? That would get rid round the export symbol table issue. > > I also recall something about the difference in x86 versus x64 symbols name > and whether they're prefixed with an underscore. But for the moment, I > think the best course of action is to resolve the decorated symbols names > first.
I cloned the repo and built with mingw-w64 x86, but used __cdecl instead of __stdcall. The import library had the right name decoration for x86 (x64 does not have a leading underscore), but the DLL had the symbol exported exactly as was specified in the .def file. The resulting executable ran. I did not try to use LoadLibrary on the DLL. Tom _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
