On Thursday 24 October 2024 14:16:59 Martin Storsjö wrote: > On Wed, 23 Oct 2024, Pali Rohár wrote: > > > On Wednesday 23 October 2024 00:06:01 Martin Storsjö wrote: > > > On Tue, 22 Oct 2024, Pali Rohár wrote: > > > > > > > On Tuesday 22 October 2024 23:52:11 Martin Storsjö wrote: > > > > > On Sat, 19 Oct 2024, Pali Rohár wrote: > > > > > > > > > > > libmsvcrtd.a is import library for msvcrtd.dll and therefore it > > > > > > cannot > > > > > > include libmsvcrt_extra.a library which object files are compiled > > > > > > with > > > > > > -D__LIBMSVCRT_OS__ which instruct code to access msvcrt.dll library. > > > > > > > > > > > > Add a new static library libmsvcrtd_extra.a which is compiled from > > > > > > subset > > > > > > of libmsvcrt_extra.a sources which does not depend on msvcrt.dll and > > > > > > compile them without -D__LIBMSVCRT_OS__ option. Then use this new > > > > > > static > > > > > > library libmsvcrtd_extra.a for building the final libmsvcrtd.a > > > > > > import library. > > > > > > --- > > > > > > mingw-w64-crt/Makefile.am | 43 > > > > > > +++++++++++++++++++++++++++++++-- > > > > > > mingw-w64-crt/lib32/msvcrtd.mri | 2 +- > > > > > > 2 files changed, 42 insertions(+), 3 deletions(-) > > > > > > > > > > Thanks - this version does compile correctly. > > > > > > > > > > I'd like to point out, that this patch does add a bit of maintainance > > > > > burden > > > > > - there's yet another new src_<library> variable with a lot of source > > > > > files, > > > > > that needs to be taken into account whenever we move functions around > > > > > between the libraries. The rule for exactly which files from > > > > > src_msvcrt that > > > > > are included and which ones aren't, isn't very obvious either. > > > > > (Include all > > > > > files except the ones that trigger #error?) > > > > > > > > > > When judging whether we should add these debug variants of CRTs, one > > > > > factor > > > > > was/is how much extra maintainance burden they add; this new > > > > > information > > > > > makes me wonder if we really do need an import library for this DLL > > > > > at all? > > > > > > > > > > // Martin > > > > > > > > This is just a way how source files are currently defined in the > > > > Makefile.am. > > > > > > Yes, but this adds yet another list that I'm not very interested in > > > maintaining. > > > > > > You didn't mention what the exact logic is for which files are included > > > and > > > excluded compared with the list of files for the regular msvcrt.dll - I > > > think that should be spelled out somewhere. > > > > I took files which did not cause compile errors. > > Right - what happens if you'd try to use this msvcrtd import library and try > to call one of those functions that you omitted then?
Before this change, application used GetModuleHandle on msvcrt.dll (not msvcrtD.dll) and tried to resolve that called function. So if the msvcrt.dll was loaded then there was a mix of msvcrt.dll and msvcrtd.dll calls -- which is wrong. With this change, linker throws a link error about undefined symbol. Same behavior as tryign to link against msvcrt40.dll or msvcr70.dll which do not provide that symbol neither. We can extend mingw-w64 source of those function, so they can be compiled also for msvcrt40, msvcr70, msvcrtd, ... if needed. > > > > I was thinking about improving this situation by defining variables like > > > > src_up_to_msvcr100, src_up_to_msvcr80, ... as lot of source files are > > > > statically linked into more msvcr libraries. There is common pattern: > > > > if the msvcrX introduced function F then emulation of F is included in > > > > all versions prior X. And this should reduce the maintenance problems. > > > > > > Hmm, perhaps that would help with the duplication a bit - I'm not entirely > > > sure if that ends up more or less maintainable, but maybe it's good to try > > > and see what it ends up looking like? > > > > > > // Martin > > > > In the attachment is such attempt. What do you think about it? > > Viewing diff is not the best option, better is to apply it and look. > > > > Fix for msvcrtd would then look like this, which is pretty > > straightforward without any maintenance burden: > > > > diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am > > index 0be41ac39274..f6c2bc6e4d11 100644 > > --- a/mingw-w64-crt/Makefile.am > > +++ b/mingw-w64-crt/Makefile.am > > @@ -802,6 +802,12 @@ src_msvcrt40=\ > > $(src_pre_msvcr100) \ > > $(src_pre_msvcr120) > > > > +src_msvcrtd=\ > > + $(src_pre_msvcr70) \ > > + $(src_pre_msvcr80) \ > > + $(src_pre_msvcr100) \ > > + $(src_pre_msvcr120) > > + > > src_msvcr70=\ > > $(src_pre_msvcr80) \ > > $(src_pre_msvcr100) \ > > This looks more manageable, yes. > > // Martin Ok. If you like the attached diff in the previous email, please let me know if it is needed something more with it for committing. Then I can prepare a new version of msvcrtD based on that diff. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
