On Sun, 8 Feb 2026, LIU Hao wrote:
在 2026-2-8 06:22, Martin Storsjö 写道:
But this one doesn't seem to be generic enough - it seems to assume a
specific layout between the build directories for crt and headers.
I presume this is for the case of building both through the toplevel
autoconf files in the project root? So you'd have a build directory, with
mingw-w64-headers and mingw-w64-crt build directories next to each other in
it?
When using the top-level configure, it is the case. This structure is
required by recursive make.
Sure.
I'm not against doing this - but it would be nice to be able to get the
same benefit (of linking a header build tree with a crt build) when
building without the top-level configure as well, with some other option
to point towards that other header build tree, like
--with-headers-builddir= or so. If using the toplevel configure, it could
and should of course find that automatically.
In theory we could generate a separate _mingw.h for use in the build of the
crt as well. Most things (like default CRT, default _WIN32_WINNT) doesn't
really matter, as it is overridden anyway, during the build of the crt
files. But if we want to build tests too (not sure yet if this patchset
gets there or not), we'd want to have the real values of those. The default
CRT is known here anyway.
GCC does not search `-L` directories for CRT object files ({,g,dll}crt2.o),
so this setup only allows building the CRT itself.
Hmm, right, that's true - I didn't think of that.
In order to build tests, the CRT has to be installed first; and in that
case, test programs are linked against pre-installed CRT object files.
But such an issue has always been there.
Yep, that's true.
Would you think that it would be worthwhile to support building the tests
against the current built libs without installing them, even if it would
end up using the old ({,g,dll}crt2.o)? On one hand, it would make testing
things simpler, for the majority of cases that don't touch those object
files. On the other hand, it would give incorrect test results for the few
patches that actually do touch those files. We couldn't rely on such a
setup in e.g. CI as it wouldn't test things properly though... For local
testing, it could make things slightly simpler, and would fix cases where
a "make check" requires the changes from the latest built libraries
though.
Practically, it mostly would just be to add like -Llib32 to the test
build, in addition to the -isystem flags you add here.
Overall, I like the direction, I've been thinking about something like this
too, for being able to build and run crt tests without installing the built
libraries as well.
Wile doing these changes, I noticed that `MINGW_HAS_DDK_H` is defined
indirectly by _mingw.h. Technically, macros in there must be reserved names.
Do you think DDK can be removed from repo?
I honestly don't know. It would certainly be nice to be able to get rid of
it, but I think we'd need to ask around quite widely and loudly before I'd
be comfortable doing it.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
