On Thursday 10 March 2022 15:01:20 Martin Storsjö wrote: > Hi, > > On Mon, 7 Mar 2022, Pali Rohár wrote: > > > There are more variants of msvcrt runtime libraries and mingw-w64 > > currently does not build import library for each variant. Some variants > > are available in all Windows versions as system libraries, some are > > available only via external redistributable package. > > > > Build import libraries also for msvcrt10.dll, msvcrt20.dll, > > msvcrt40.dll, msvcr70.dll and msvcr71.dll runtime libraries during > > mingw-w64 build procedure. > > > > With these patches it is possible for application or plugin compiled > > by mingw-w64 to link with any of these dll libraries. > > > > If e.g. existing application was compiled by Visual Studio 2003 and it > > supports loadable plugins, then new plugin may be developed and compiled > > by mingw-w64 with linking to msvcr71.dll (Visual Studio 2003 CRT) via > > libmsvcr71.a import library, which is build by this patch series. > > Hmm. I'm not very thrilled about adding these extra DLL targets - but they > doesn't seem to add too much of an extra burden either (especially as they > are only for i386 and not for x86_64). Principally, I'm more ok with adding > support for the ones that are shipped in Windows than the ones that has to > be redistributed separately. I do know we have import libraries for a couple > such ones though - I'm not sure how well tested they are though. Some of > them were added for specific needs (like msvcr120_app for early WinStore > applications), but others, I'm not sure if they've ever been used much/at > all (and at times, I've considered if we should clean them out). > > For these ones you're proposing to add, do you have a specific real concrete > usecase, or is it just for completeness? (The cases with building plugins > for apps linked with a specific CRT sounds mostly hypothetical to me, but if > it's something you're actually doing, I'd be interested to hear about it. > And even then, I guess any CRT should work as long as there's no CRT > resources shared over the DLL boundaries.) > > So in short - I'm not strongly opposed to these patches and I don't have any > strong reason why they shouldn't be merged, but I'd like to hear more about > the actual motivation behind the patches. > > // Martin
Hello! It is rather for completeness. But I used it now for testing and for compilation of applications. And e.g. usage of older msvcrt library found bugs in tested application (logical errors, uninitialized memory). Bugs which were not triggered by neither linux glibc runtime nor by system msvcrt.dll runtime. And msvcrt10.dll and msvcrt20.dll caused application to compute different things due to uninitialized memory. Not sure how many people are interested in these CRT runtimes, but I'm happy in any option which can help to debug issues. So I understand if you do not take them. One good argument for msvcr71.dll is that it produce slightly smaller binaries than default msvcrt.dll because msvcr71.dll contains some functions which msvcrt.dll does not have and which mingw-w64 links statically. Well, in the end decide if you want it or not. Everything is just 32-bit (none of these libraries were released in 64-bit form as they are pre-2003) and basically touches only Makefiles and .def files. For me is this mingw-w64 interesting project as it easily allowed me to use new compiler (C11) with every older CRT version and run automated regression tests. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
