Hi Jon, > This approach keeps 'goes in DLL' next to the function itself, which I > like. If you're interested, another possible approach here is to use > .DEF files with MSVC, which can also do symbol aliasing: > https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using- > def-files > > I would expect mingw to support .DEF files as well, but I don't know.
I did use .DEF file initially. However, when adopting the project to build with MinGW too, my limited knowledge in authoring Linux build systems didn't find a way to use .DEF files there. After some research, I have put the export declarations into the source code instead. It's ugly but it keeps both building systems happy and produces consistent DLL file. > Only x86 Win32 functions are actually __stdcall; x64, ARM32, and ARM64 > all ignore the token because the architectural calling convention makes > it > meaningless: > https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx > > This is why the names don't get mangled. Of course, it's then > inconsistent. > > Export name consistency is needed so CustomActions can reference the > export symbol name, right? Exactly. That extra effort to prevent name mangling when compiling x86 DLL file pays off later when authoring MSI package. Otherwise, I would have had to introduce some "#if-s" in WiX to address different platform-specific function names. I had to pick my poison, and I choose to fix issues as close to the source as possible. Regards, Simon
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
