From: Kai T. <kti...@go...> - 2012-05-15 18:54:18
|
2012/5/15 MARTIN Pierre <hic...@gm...>: > Kai, > >> Well, that isn't surprising, as VC doesn't use msvcrt.dll from OS. It >> provides its own msvcr??.dll version by of course contains this >> symbol. > Understood. > >> You can build your application with gcc also for different >> runtime-library, but you have to specify it manually. Also be aware >> that more modern runtimes need manifest-files to let the >> application start. > i will try to get it to compile against the 8.0 version then. > > There is something i don't understand tho: > When compiling my application, let's say it calls _wsopen_s. > The compiler looks in the .h, and finds the definition. Then, > the linker looks in the .a of msvcrt, and here is my problem, > why isn't it warning about anything? Neither the linker nor the compiler can know on what OS this application might be executed. It is perfectly valid to build a Windows 64-bit application on a 32-bit Windows OS by using one of our cross-compilers. Also it is possible to build a 32-bit application by our toolchain on a Win2000 OS, but exectute it on Vista, etc. So there is no way to detect this and no valid way to warn about it. > Would it mean that the > msvcrt.a from MinGW-w64 has the _wsopen_s function, while > in fact it is not present in the msvcrt DLL from the system? Our import-library provides this export. For 64-bit OS this export is always present, so we didn't noticed this issue. But as this function is present at least beginning with VC 2005 it should be supported by XP's msvcrt.dll version. > Also, when i usually ship the application to a customer, the > only thing i give along with the installer is the VC++ runtimes. > Would that also mean that the VC++ runtimes contains the > required version of the msvcr80.dll? yes > In this case, wouldn't be the job of the MinGW runtime to export > the right fonctions at compile time, and warn with linker errors > when they cannot be found? Again, if this function is present on the final OS used to execute the built application isn't detectable and it is no good to check build OS, if there this export is present. If you want to make sure that export is always present you need to build you application against msvcr??.dll instead of msvcrt.dll. > Thanks for explaining, this is very interesting. > Pierre. Regards, Kai |