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 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
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public