MSYS2 environments + naming

[lazka]

MSYSTEM=MSYS

• filesystem: /
• package prefix: ``

MSYSTEM=MINGW32

• filesystem: /mingw32
• package prefix: mingw-w64-i686-

MSYSTEM=MINGW64

• filesystem: /mingw64
• package prefix: mingw-w64-x86_64-

Potential new ones:

MSYSTEM=CLANG64 (can still be changed)

• filesystem: /clang64
• package prefix: mingw-w64-clang-x86_64-

Less clear potential new ones:

• mingw + x86_64+ gcc + ucrt?
• mingw + arm64 + gcc/clang? + ucrt?

Some patterns that emerge that might be nice to preserve:

• mingw packages start with "mingw-w64-", while msys ones don't
• lowercase MSYSTEM matches the filesystem root

---

My vote goes to

• MSYSTEM=ARM64 root=/arm64 prefix=mingw-w64-arm64 (arm64 is the MS naming and thus more widely known among users I'd asume)
• MSYSTEM=MINGW64U root=/mingw64u prefix=mingw-w64-ucrt-x86_64

but I'm open to other ideas

(other problems we have is no CI for arm64 (looking-towards-remond) and disk space on our repo server)

[Biswa96]

My vote goes to "MINGWARM64" because in mingw-w64 repo, lib64 -> libarm64, so MINGW64 -> MINGWARM64. Hence:

• MINGW_PREFIX=/mingwarm64 (meh!)
• MINGW_CHOST=aarch64-w64-mingw32 (this one will match with GCC/Clang targets)
• MSYSTEM_CARCH=aarch64
• MINGW_PACKAGE_PREFIX=mingw-w64-aarch64 (this one with match with ArchLinux ARM)

[mati865]

If this would be cross-compilation target then CHOST would be x86_64-w64-mingw32.

[mati865]

I think there are many people who want different thing with AArch64:

• native target
• cross-compiled from x86_64

Any thoughts?

[jeremyd2019]

I have been working on a sort of 'proof-of-concept' building of packages mostly natively on AArch64 (after cross-compiling the toolchain) utilizing msys2/i686. This seemed the most straightforward approach. However, a strong argument can be made for cross-compiling, due to the lack of (powerful) hardware, and especially the lack of a Windows on ARM GitHub runner for automated builds. An argument against cross-compiling might be, if you're going to be cross-compiling anyway, why not cross-compile from Linux, where the POSIX-y tools are a whole lot faster?

[Biswa96]

Native Windows ARM system is not so widespread, cross-compilation will be more viable option.

[jeremyd2019]

Last night I started trying to get windows 10 arm64 preview build installed on a raspberry pi (3B+). Apparently it's possible. No idea if it's at all usable for purpose.

[jeremyd2019]

I certainly hope for an ARM64 Windows Github Actions runner 🤞

[Biswa96]

In Ci, it is possible to download and use llvm-mingw toolchain https://github.com/mstorsjo/llvm-mingw

[jeremyd2019]

I did a test today, building llvm/clang for aarch64 host, on x86_64 vm and on raspberry pi 3B+. By the time the raspberry pi finished the first cmake run, the x86_64 vm finished building llvm/clang and was starting on libc++. 😬

[jeremyd2019]

In case anybody is curious, my test build of llvm/clang on the raspberry pi did eventually finish, in about 5 and a half days.

[jeremyd2019]

I got to the point of building llvm/clang using a native aarch64 clang rather than the x86-emulated clang running on msys2. That build completed in only about 2 days, and included more projects (the MINGW-packages version rather than the CLANG-packages version).

[jeremyd2019]

I've been playing with:

• MSYSTEM=CLANGARM{32,64}
• MINGW_PREFIX=/clangarm{32,64}
• MINGW_CHOST={armv7,aarch64}-w64-mingw32
• MINGW_PACKAGE_PREFIX=mingw-w64-clang-{armv7,aarch64}

for a mainly 'native' target

[Biswa96]

Do we need armv7?

[jeremyd2019]

Gee, I didn't even think about need, it just fit nicely with i686/x86_64 🤣

[jeremyd2019]

One interesting thing is that $MSYSTEM affects the output of uname. When I was messing around, cmake was complaining about not knowing about CLANGARM64_NT-10.0-19042 and needing a platform file when being run with -DCMAKE_CROSSCOMPILING=ON.

[jeremyd2019]

Another place that's looking at uname for MINGW: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-zlib/01-zlib-1.2.11-1-buildsys.mingw.patch#L41

I hate to suggest something so verbose, but maybe MSYSTEM=MINGWCLANGx would work better? Or some other solution that allows uname to stay MINGW?

[lazka]

We could force uname to (MSYSTEM == MSYS) ? MSYS : MINGW or similar. I'm not a fan of it leaking MSYSTEM anyway.

[Biswa96]

@jeremyd2019 What compiler are you using? I've compiled those basic packages using llvm-mingw without any issue. The only thing that I don't have, is a server to share those.

[jeremyd2019]

What compiler are you using?

msys2/CLANG-packages#2

[jeremyd2019]

We could force uname to (MSYSTEM == MSYS) ? MSYS : MINGW or similar. I'm not a fan of it leaking MSYSTEM anyway.

Not wanting to spend time at the moment for a sane rule like that, I did a quick hack to translate CLANG into MINGW. Luckily they're both 5 characters long. 😛 jeremyd2019/msys2-runtime@b5dbd99

[jeremyd2019]

Adding more MINGW_PACKAGE_PREFIX values could result in an explosion of copy/pasted package function wrappers for split packages. The best thing I was able to come up with to deal with this in a PKGBUILD is:

diff --git a/mingw-w64-libiconv/PKGBUILD b/mingw-w64-libiconv/PKGBUILD
index 4629c927924..1c9ae27795a 100644
--- a/mingw-w64-libiconv/PKGBUILD
+++ b/mingw-w64-libiconv/PKGBUILD
@@ -100,7 +100,5 @@ _package_iconv() {
   install -Dm644 "${srcdir}/${_realname}-${pkgver}/COPYING" "${pkgdir}${MINGW_PREFIX}/share/licenses/iconv/COPYING"
 }
 
-package_mingw-w64-i686-iconv()      { _package_iconv;    }
-package_mingw-w64-i686-libiconv()   { _package_libiconv; }
-package_mingw-w64-x86_64-iconv()    { _package_iconv;    }
-package_mingw-w64-x86_64-libiconv() { _package_libiconv; }
+eval "package_${MINGW_PACKAGE_PREFIX}-iconv()      { _package_iconv;    }"
+eval "package_${MINGW_PACKAGE_PREFIX}-libiconv()   { _package_libiconv; }"

🤮 I was also thinking that makepkg could be patched to look for a package function with MINGW_PACKAGE_PREFIX stripped from the package name if a package function with it included could not be found. That might be cleaner than building functions with eval.

[jeremyd2019]

I encountered another convention that might need adjustment for clang vs gcc packages for the same arches... Many packages use install script names of the form <package>-${CARCH}.install, which have the MINGW_PREFIX hardcoded in them. If there were, for example, x86_64 packages in /mingw64 and /clang64, that naming convention wouldn't work anymore as both would use <package>-x86_64.install

[mati865]

This is one of the reasons why pacman hooks are so much better than install scripts.
You create only one hook using MINGW_PREFIX internally. That allows it to work for all subsystems.

[lazka]

I had to prefix everything in hooks as well, unless I missed something. See https://packages.msys2.org/package/mingw-w64-x86_64-gtk-update-icon-cache?repo=mingw64 for example

hooks can at least be generated using templates though

[mati865]

Yeah, I meant templates.

[jeremyd2019]

well, the simplest thing would be to just switch from using $CARCH to using ${MINGW_PREFIX#/} or $MINGW_PACKAGE_PREFIX in the naming. Doesn't help with the explosion of near-identical copies of scripts though...

[lazka]

I went with copying for now: msys2/MINGW-packages#8211