> On Aug 27, 2018, at 22:07, Jacek Caban <ja...@codeweavers.com> wrote: > > On 08/27/2018 08:44 PM, Martin Storsjö wrote: >> On Mon, 27 Aug 2018, Jacek Caban wrote: >> >>> Please review the attached patch. >>> >>> Note that it adds .mri file in a different way than those that are >>> currently in the tree. I don't like how much copy&paste between >>> arch-specific rules it would require otherwise. Being not an expert of >>> autoconf, I'd appreciate good review of those parts. >>> >>> --- >>> mingw-w64-crt/Makefile.am | 67 ++++++++ >>> .../lib-common/api-ms-win-core-version-l1-1-1.def | 10 ++ >>> mingw-w64-crt/lib-common/mincore.mri | 168 >>> +++++++++++++++++++++ >>> mingw-w64-crt/lib32/Makefile.am | 1 + >>> .../lib32/api-ms-win-core-version-l1-1-1.def | 10 ++ >>> mingw-w64-crt/lib64/Makefile.am | 1 + >>> mingw-w64-crt/libarm32/Makefile.am | 1 + >>> mingw-w64-crt/libarm64/Makefile.am | 1 + >>> 8 files changed, 259 insertions(+) >>> create mode 100644 >>> mingw-w64-crt/lib-common/api-ms-win-core-version-l1-1-1.def >>> create mode 100644 mingw-w64-crt/lib-common/mincore.mri >>> create mode 100644 >>> mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def >> >> LGTM >> >> I'd also appreciate a patch that does similar deduplication for the >> other existing .mri files :-) > > Thanks, I will push it.
This broke building for arm64, since libmincore.a depends on libauthz.a and libmswsock.a, which aren't yet in lib-common and thus not available for arm64. I pushed a quick workaround by just disabling building libmincore.a for arm64 for now, I didn't look into how hard it would be to move these def files to lib-common. // Martin ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
