On Thursday 10 March 2022 22:51:12 Pali Rohár wrote: > 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.
Hello! Any opinion on this? _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
