Unix tools: move away from MSYS2 (if possible) #12636

longnguyen2004 · 2020-07-29T14:30:24Z

Is your feature request related to a problem? Please describe.
There are several projects like win-bash, UnxUtils and GnuWin32 that provides most of the tools needed for bash/autotools-based build systems. If we can move to one of these projects, we can avoid the slow build time caused by MSYS2

linquize · 2020-07-29T14:54:34Z

The tools in these projects were very old, over 10 years not updated.

Neumann-A · 2020-07-29T15:25:28Z

VCPKG could probably build all those tools itself which I am strongly in favor of. Some of those tools are also simply scripts. Depending on MSYS will always occasionally break VCPKG.

longnguyen2004 · 2020-07-29T15:39:50Z

The tools in these projects were very old, over 10 years not updated.

We don't really need up to date tools for these, unless the build system depends on some new features

longnguyen2004 · 2020-07-29T15:43:09Z

And AFAIK win-bash is still active (last update around 2019) so I think it's fine

linquize · 2020-07-29T15:45:56Z

And AFAIK win-bash is still active (last update around 2019) so I think it's fine

Where is it ?

longnguyen2004 · 2020-07-29T15:50:57Z

Whoops I misread something, sorry for that xD
But still moving away from MSYS2 is crucial for performance and compatibility with 32 bit systems (not that I use 32 bit Windows myself, but it's nice to have)

MVoz · 2020-07-31T21:02:17Z

@longnguyen2004
busybox ?

...
    set(TOOLSUBPATH busybox64)
    set(URLS "https://frippery.org/files/busybox/busybox-w64-FRP-3532-g01a256149.exe")
    set(_vfa_RENAME "busybox.exe")
    set(ARCHIVE "busybox-w64-FRP-3532-g01a256149.exe")
    set(NOEXTRACT ON)
    set(HASH ba5143ebc54c499923e7289336e236d7b833f153ac7b6fe633433dbfc3bfc453825671e6f39de5dcf9279b2942f3040cd1110947fc5943798d093e2b38e19b11)
    set(STAMP "initialized-busybox64.stamp")
  else()
    set(TOOLSUBPATH busybox86)
    set(URLS "https://frippery.org/files/busybox/busybox-w32-FRP-3532-g01a256149.exe")
    set(_vfa_RENAME "busybox.exe")
    set(ARCHIVE "busybox-w32-FRP-3532-g01a256149.exe")
    set(NOEXTRACT ON)
    set(HASH 74786326c07c1cf2b11440cbd7caf947c2a32ebcc2b5bb362301d12327a2108182f57e98c217487db75bf6f0e3a4577291933e025b9b170e37848ec0b51a134c)
    set(STAMP "initialized-busybox86.stamp")
...


    vcpkg_execute_required_process(
      ALLOW_IN_DOWNLOAD_MODE
      COMMAND ${BUSYBOX_SETUP} --install ${PATH_TO_ROOT}
      WORKING_DIRECTORY ${TOOLPATH}
      LOGNAME busybox-setup-${TARGET_TRIPLET}
    )


Currently defined functions:
        [, [[, ar, arch, ash, awk, base64, basename, bash, bunzip2, busybox, bzcat, bzip2, cal,
        cat, chattr, chmod, cksum, clear, cmp, comm, cp, cpio, cut, date, dc, dd, df, diff,
        dirname, dos2unix, dpkg, dpkg-deb, du, echo, ed, egrep, env, expand, expr, factor, false,
        fgrep, find, fold, fsync, ftpget, ftpput, getopt, grep, groups, gunzip, gzip, hd, head,
        hexdump, httpd, iconv, id, inotifyd, ipcalc, kill, killall, less, link, ln, logname, ls,
        lsattr, lzcat, lzma, lzop, lzopcat, man, md5sum, mkdir, mktemp, mv, nc, nl, od, paste,
        patch, pgrep, pidof, pipe_progress, pkill, printenv, printf, ps, pwd, readlink, realpath,
        reset, rev, rm, rmdir, rpm, rpm2cpio, sed, seq, sh, sha1sum, sha256sum, sha3sum, sha512sum,
        shred, shuf, sleep, sort, split, ssl_client, stat, strings, su, sum, tac, tail, tar, tee,
        test, time, timeout, touch, tr, true, truncate, ts, ttysize, uname, uncompress, unexpand,
        uniq, unix2dos, unlink, unlzma, unlzop, unxz, unzip, usleep, uudecode, uuencode, vi, watch,
        wc, wget, which, whoami, whois, xargs, xxd, xz, xzcat, yes, zcat

longnguyen2004 · 2020-07-31T23:24:04Z

Seems good enough for the job, just need GNU make (Chocolatey has 4.3). @ras0219-msft what do you think?

longnguyen2004 · 2020-08-01T06:42:37Z

Perl would be a problem though, I haven't known yet if the openssl build system can use native Perl or not...

linquize · 2020-08-02T08:24:33Z

msys2 download time is relatively long.

vcpkg download msys2.
msys2's pacman update packages to latest.

I do not understand that building such a small library zlib requires msys2.

longnguyen2004 · 2020-08-02T10:57:48Z

I thought zlib uses CMake, no? That's probably the pkg-config part, we could use a standalone pkg-config for that.
The real problem is with Perl-based build systems, such as openssl, which will die on native Perl due to backward-vs-forward slash. Patching that out results in the configure script writing unescaped backslashes into the code.
Also, Busybox is not a true Unix environment, and also have other oddities (such as mapping / to the current drive, which makes any scripts using /tmp, /usr,... to either fails, or clutters the drive root with folders)

linquize · 2020-08-02T11:06:31Z

zlib portfile.cmake has vcpkg_fixup_pkgconfig() that calls vcpkg_acquire_msys(pkg-config)

Can we download standalone pkg-config for windows, instead of the whole msys2?

linquize · 2020-08-02T13:07:02Z

For vcpkg_fixup_pkgconfig(),
Downloading msys2 base files http://repo.msys2.org/distrib/x86_64/msys2-base-x86_64-20190524.tar.xz +
pkg-config https://repo.msys2.org/msys/x86_64/pkg-config-0.29.2-1-x86_64.pkg.tar.xz
is enough.
Extract only /usr/bin/pkg-config.exe from pkg-config-0.29.2-1-x86_64.pkg.tar.xz is enough.

No need to run pacman that spends too much time updating all the packages before installing pkg-config.

Neumann-A · 2020-08-02T13:30:18Z

@linquize the idea is not new see #12626

longnguyen2004 · 2020-08-02T14:57:40Z

About using BusyBox as a substitute for common Unix tools:
Seems like autotools-based build systems don't like it, it complains about missing awk, sed, grep,... so I end up having to do AWK="awk" SED="sed" GREP="grep" ...
Also, native make has some differences compared to MSYS2 make. It defaults to using COMSPEC for the shell, which breaks pretty much all autotools Makefiles. Adding SHELL=sh to the make invocation might work

MVoz · 2020-08-02T15:10:44Z

@Neumann-A

why not, an auxiliary utility, if it really helps in the assembly, then obviously can use it?
substitute MSYS I wouldn't recommend using only as an add-on (busybox)

@longnguyen2004
cygwin ? )))
https://github.com/Voskrese/vcpkg-template/blob/master/scripts/cmake/vcpkg_acquire_cygwin.cmake

longnguyen2004 · 2020-08-02T15:24:58Z

@voskrese nope that's pretty much same as msys2 xD I need fast GNU make for openssl

longnguyen2004 · 2020-08-02T15:58:40Z

Alright, current state of my BusyBox test:

Build systems	Workaround
autotools-based	Need to specify `PATH_SEPARATOR=";"`, since BusyBox doesn't convert path separators for us. Also needs `AWK="awk" SED="sed" ...`. Resulting Makefiles need to be run with `SHELL=sh.exe`
Simple Perl-based (libvpx)	Needs some patching to the configure script, due to `diff --version` not returning 0 on BusyBox, otherwise builds fine
Complex Perl-based (openssl)	Needs to remove forward slash check, but then it writes unescaped backslashes into the source file (I'm using ActiveState, Strawberry might be different)

And that's only for common tools. Other ports might require tools such as m4, which needs MSYS2 anyway.

longnguyen2004 · 2020-08-08T04:49:29Z

~~I've just tested ICU today and it doesn't like BusyBox. Seems like we'll have to stick with MSYS2 for now~~ Nevermind, just need some patching and it's working now

ras0219 · 2020-08-10T16:14:59Z

For pieces that still require Msys, we can use a technique like in #12626; download the packages directly and manually unpack them together instead of using pacman. Most (all?) of our observed msys instability comes from the package manager and silent updates, not from the actual binaries.

Obviously other solutions like busybox are fine too (and may be less complicated if the msys version has lots of dependencies!), but I think we can pick-and-choose on a per-tool basis what's best.

longnguyen2004 · 2020-08-11T03:26:31Z

One thing to note: The current busybox binary on the site doesn't have install, so if someone wants to test it out, you should grab the source and build it yourself

longnguyen2004 · 2020-08-11T07:34:04Z

What ports are still using sh-based build systems in vcpkg? I wanna do a test on all of them to determine if it's viable to switch to busybox

JackBoosY · 2020-08-11T08:16:22Z

@longnguyen2004 You can find using the keyword vcpkg_configure_make, vcpkg_acquire_msys and vcpkg_find_acquire_program(YASM).

Neumann-A · 2020-08-11T11:41:04Z

PR #9966

linquize · 2020-08-11T13:33:06Z

Why related to #9966?

longnguyen2004 · 2020-08-13T08:47:52Z

I'll update this comment as I continue my testing
~~All autotools-based build systems require replacing /bin/sh with sh, as busybox doesn't recognize the former~~ A recent commit allowed /bin/sh to work. Also we need to explicitly pass tool names (awk, sed, grep,...) and targets (as it can't recognize the target)
All libtool-based build systems require these 2 patches to configure and ltmain.sh/libtool
All tests are done with x64-mingw-dynamic triplet
Additional tools that might be needed:
m4, libregex (for m4)
Configure command: ./configure PATH_SEPARATOR=";" AWK="busybox awk" SED="busybox sed" GREP="busybox grep" DIFF="busybox diff" PATCH="busybox patch" AR="ar.exe" CC="cc" CXX="c++" STRIP="strip" RANLIB="ranlib" RC="windres" WINDRES="windres" --prefix=... --build=... --host=...
Make command: PATH_SEPARATOR=";" AWK="busybox awk" SED="busybox sed" GREP="busybox grep" DIFF="busybox diff" PATCH="busybox patch" AR="ar.exe" CC="cc" CXX="c++" STRIP="strip" RANLIB="ranlib" RC="windres" WINDRES="windres" make SHELL="busybox sh" -j4 (some libs run configure during make)

vcpkg_configure_make

Libraries	Build system type	Result	Additional notes
libcrafter	autotools	UNTESTED	Requires autoconf
libb2	autotools + libtool	PASS
libmagic	autotools + libtool	PASS
libosip2	autotools + libtool	PASS
libwandio	autotools + libtool	SKIP	Doesn't support Windows
farmhash	autotools + libtool	PASS
libudns	autotools	SKIP	Doesn't support Windows
unixodbc	autotools + libtool	SKIP	Doesn't support Windows
openmpi	autotools	SKIP	Doesn't support Windows
x264	Custom	PASS
hwloc	autotools	SKIP	Custom CMakeList.txt available
healpix	Custom (healpix) + autotools + libtool (libsharp)	FAIL	No way to pass target to libsharp
libmicrohttpd	autotools + libtool	~~FAIL~~ PASS	Works after applying my patch
gperftools	autotools + libtool	SKIP	Custom CMakeList.txt available
libmesh	autotools + libtool	PASS	Requires m4 for netcdf. Compile fails, but configure works
ocilib	autotools + libtool	PASS
sdl1	autotools + libtool	PASS
libusb	autotools + libtool	PASS
freexl	autotools + libtool	PASS
tcl	autotools	PASS
nettle	autotools	PASS	Requires m4
pbc	autotools + libtool	PASS
gmp	autotools + libtool	PASS
libxslt	autotools	SKIP	MSVC + mingw makefile available
mpg123	autotools + libtool	SKIP	CMakeList.txt available, should we switch?
mpir	autotools + libtool	PASS	Mark as PASS since gmp also passes
libpq	autotools	UNTESTED	Not tested yet due to size constraints

vcpkg_acquire_msys

Libraries	Build system type	Result	Additional notes
kf5i18n	CMake	SKIP	Only used for `gettext`
ffnvcodec	None	SKIP	Only used for copying headers
openssl-unix	Custom	FAIL	Requires MSYS2 (Unix) Perl
libvpx	Custom	PASS	patch `configure`: `diff --version` -> `command -v diff`
tensorflow-cc	Bazel	UNTESTED	Not tested yet due to Bazel dependency
ffmpeg	Custom	PASS
icu	autotools	PASS	patch `pkgdata.cpp`: `bash -c \"%s\"` -> `\"%s\"`)

longnguyen2004 · 2020-08-20T11:21:22Z

AR="ar.exe" CC="cc" CXX="c++" STRIP="strip" RANLIB="ranlib" RC="windres" WINDRES="windres

That is not a native windows build environment. You need to change it to use cl, link, lib and rc

I'm gonna pick a few random ones and test with cl. I expect most of them to have similar results.
But to be fair, most of them already have VS projects, so I don't think it'll make a difference.

mingwandroid · 2020-08-21T12:24:28Z

I do not understand the motivation here. Can someone help?

You are moving from a well tested, constantly updated Linux-like distro to some custom builds. This seems like a big effort for little gain because of some perceived slowness of pacman updates? You could use the nightly installs (so less gets installed), or else install exactly what you need. You can cache all the packages needed too if download speed is an issue. We use zstd now so our packages unpack very very quickly indeed and they compress very well too.

BillyONeal · 2020-08-21T17:37:06Z

You are moving from a well tested, constantly updated Linux-like distro to some custom builds.

The problem is that the 'constantly updated' part results in breaking vcpkg seemingly every week or so. pacman doesn't seem to like being driven in an automated way like we do, and when it prompts for input or otherwise becomes unhappy we waste ~92 hours of compute time.

I believe @ras0219 was looking at downloading the packages from msys directly rather than relying on pacman as an alternate fix.

Neumann-A · 2020-08-21T17:52:17Z

that is #13019

mingwandroid · 2020-08-21T18:11:22Z

Pacman can be fully automated. Check the help. You can also point it at your own repository if you are unhappy with the stability of msys2 and curate the package updates manually.

linquize · 2020-08-21T23:41:05Z

@mingwandroid Currently Microsoft does not host its own repositories for the tools, URLs always point to official download locations.

MVoz · 2020-08-22T00:02:05Z

an alternative is always needed, but not on a permanent basis. msys2 and pacman work properly.

longnguyen2004 · 2020-08-22T02:09:41Z

The other problem is the size. Although this is somewhat better now due to the use of zstd, but as of today, BusyBox is still way lighter than MSYS2 installer (~500KiB vs ~90MiB) and also works pretty well with the libraries I've tested (see above).

MVoz · 2020-08-22T05:44:22Z

BusyBox a stripped-down version of the main utilities and commands

BusyBox sed --help

Usage: sed [-i[SFX]] [-nrE] [-f FILE]... [-e CMD]... [FILE]...
or: sed [-i[SFX]] [-nrE] CMD [FILE]...
    -e CMD  Add CMD to sed commands to be executed
    -f FILE Add FILE contents to sed commands to be executed
    -i[SFX] Edit files in-place (otherwise sends to stdout)
            Optionally back files up, appending SFX
    -n      Suppress automatic printing of pattern space
    -r,-E   Use extended regex syntax
    -b      Keep CR/LF (Windows-only)
If no -e or -f, the first non-option argument is the sed command string.
Remaining arguments are input files (stdin if none).

sed --help

Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...

-n, --quiet, --silent
suppress automatic printing of pattern space
-e script, --expression=script
add the script to the commands to be executed
-f script-file, --file=script-file
add the contents of script-file to the commands to be executed
--help display this help and exit
--text switch to text mode
-V, --version output version information and exit

and this will be seen in errors during compilation

longnguyen2004 · 2020-08-24T08:10:40Z

Here's my results with MSVC:
Configure command: PATH_SEPARATOR=";" AWK="busybox awk" SED="busybox sed" GREP="busybox grep" DIFF="busybox diff" PATCH="busybox patch" AR="lib.exe -verbose" CC="cl.exe -nologo" CXX="cl.exe -nologo" STRIP=":" RANLIB=":" RC="rc.exe" WINDRES="rc.exe" NM="dumpbin.exe -symbols -headers" DLLTOOL="link.exe -verbose -dll" ./configure --prefix=... --build=x86_64-pc-mingw32 --host=x86_64-pc-mingw32
Make command: PATH_SEPARATOR=";" AWK="busybox awk" SED="busybox sed" GREP="busybox grep" DIFF="busybox diff" PATCH="busybox patch" AR="lib.exe -verbose" CC="cl.exe -nologo" CXX="cl.exe -nologo" STRIP=":" RANLIB=":" RC="rc.exe" WINDRES="rc.exe" NM="dumpbin.exe -symbols -headers" DLLTOOL="link.exe -verbose -dll" SHELL="busybox sh" make -j4 (some libs run configure during make)

vcpkg_configure_make

Libraries	Build system type	Result	Additional notes
libcrafter	autotools	SKIP	Doesn't support Windows
libb2	autotools + libtool	PASS	portfile said it's not supported, but my build succeed?
libmagic	autotools + libtool	SKIP	Doesn't support Windows? (requires libgnurx)
libosip2	autotools + libtool	SKIP	Doesn't support MSVC
libwandio	autotools + libtool	SKIP	Doesn't support Windows
farmhash	autotools + libtool	PASS	Compile errors about `__builtin_expect` and `__builtin_unreachable`, but configure works
libudns	autotools	SKIP	Doesn't support Windows
unixodbc	autotools + libtool	SKIP	Doesn't support Windows
openmpi	autotools	SKIP	Doesn't support Windows
x264	Custom	FAIL	configure treats MS as GNU for some reason (should we switch to ShiftMedia?)
hwloc	autotools	SKIP	Custom CMakeList.txt available
healpix	Custom (healpix) + autotools + libtool (libsharp)	FAIL	No way to pass target to libsharp
libmicrohttpd	autotools + libtool	SKIP	VS projects available
gperftools	autotools + libtool	SKIP	Custom CMakeList.txt available
libmesh	autotools + libtool	SKIP	Doesn't support MSVC
ocilib	autotools + libtool	SKIP	VS projects available
sdl1	autotools + libtool	SKIP	VS projects available
libusb	autotools + libtool	SKIP	VS projects available
freexl	autotools + libtool	SKIP	MSVC makefiles available
tcl	autotools	SKIP	MSVC makefiles available
nettle	autotools	SKIP	VS projects available
pbc	autotools + libtool	SKIP	VS projects available
gmp	autotools + libtool	SKIP	Use mpir instead
libxslt	autotools	SKIP	MSVC + mingw makefiles available
mpg123	autotools + libtool	SKIP	CMakeList.txt available, should we switch?
mpir	autotools + libtool	SKIP	VS projects available
libpq	autotools	UNTESTED	Not tested yet due to size constraints

vcpkg_acquire_msys

Libraries	Build system type	Result	Additional notes
kf5i18n	CMake	SKIP	Only used for `gettext`
ffnvcodec	None	SKIP	Only used for copying headers
libvpx	Custom	FAIL	Generator shell scripts incompatible with BusyBox (ShiftMedia?)
tensorflow-cc	Bazel	UNTESTED	Not tested yet due to Bazel dependency
ffmpeg	Custom	PASS	Add `LN_S=cp -pR`

BillyONeal · 2020-08-27T21:49:56Z

I know #13019 isn't exactly what you asked for here but I think we should merge something like that, and then if you still think that's too slow we can have a continued discussion. Unless we are able to completely eliminate the msys dependency from all ports I don't think it would be a good idea to not have a single source of truth for these unix-y tools.

longnguyen2004 · 2020-08-28T06:50:17Z

Sure, after all MSYS2 is a complete Unix environment, while BusyBox is simply a collection of common Unix tools. The main problem for me is that MSYS2 make is SLOW (~30min to build openssl compared to 5-6min in WSL2), if we can find out a way to use native make then it'd be great.

Luiz-Monad · 2022-05-11T15:27:49Z

Sure, after all MSYS2 is a complete Unix environment, while BusyBox is simply a collection of common Unix tools. The main problem for me is that MSYS2 make is SLOW (~30min to build openssl compared to 5-6min in WSL2), if we can find out a way to use native make then it'd be great.

Or port it to CMake , muahahaa . autotools should die. Now seriously.

I don't need OpenSSL anymore, but I used to work on that, I think I made my own CMakeLists with the specific files I needed at the time.

I'm only writing here to ask why do we need msys to build tensorflow-common ? That entire port is a hot fire of a mess (I blame bazel for that).

hmoffatt · 2022-06-07T23:59:31Z

libiconv build also takes forever (6.5 minutes on a fast PC).

dg0yt · 2022-06-12T12:19:00Z

MSYS2 is about to move its msys subsystem (/usr) closer to cygwin: msys2/MSYS2-packages#3012.
NB: This affects the "Unix tools" which vcpkg uses for building for windows triplets. It doesn't directly affect the mingw triplets (/mingwXX).

sskras · 2023-03-15T15:14:33Z

@longnguyen2004 commented on Aug 28, 2020:

The main problem for me is that MSYS2 make is SLOW (~30min to build openssl compared to 5-6min in WSL2), if we can find out a way to use native make then it'd be great.

The Midipix project might be of some interest here, but it seems to be in pre-Alpha state yet.

Then, building it requires a Linux machine at the moment:
https://github.com/lalbornoz/midipix_build#2-building-and-deployment

Everything I do in its' version of MinTTY feels so quick.

Eg. recursive enumeration and stat()ing through a bunch of cloned GitHub repos. The MSYS2 action:

saukrs@DESKTOP-O7JE7JE MSYS ~/src
$ time find -ls | pv | wc -l
29.0MiB 0:02:51 [ 173KiB/s] [                                       <=>                                ]
190011

real    2m51.530s
user    0m10.185s
sys     0m52.967s

saukrs@DESKTOP-O7JE7JE MSYS ~/src
$ uname -a
MSYS_NT-10.0-19044 DESKTOP-O7JE7JE 3.3.6-341.x86_64 2022-10-24 08:25 UTC x86_64 Msys

The Midipix action:

midipix@DESKTOP-O7JE7JE /dev/fs/c/msys64/home/saukrs/src
$ time find -ls | pv | wc -l
28.9MiB 0:00:36 [ 809KiB/s] [                                                    <=>                   ]
190011

real    0m36.870s
user    0m0.000s
sys     0m0.031s

midipix@DESKTOP-O7JE7JE /dev/fs/c/msys64/home/saukrs/src
$ uname -a
midipix DESKTOP-O7JE7JE pre-alpha-internal-2bc731105275d52feb98f3b47cf454e7674ab739 2022.11.18.20.22.52 x86_64 Midipix

Thinking about how to benchmark fork() in a simple way.
Here it goes:
(EDIT: I removed the CPU-intensive load from the loop)

saukrs@DESKTOP-O7JE7JE MSYS ~/src
$ time seq 1 1000 | while read; do echo $REPLY | cat | cat | cat | cat; done | tail -2
999
1000

real    2m1.428s
user    0m54.068s
sys     1m43.599s

midipix@DESKTOP-O7JE7JE /dev/fs/c/msys64/home/saukrs/src
$ time seq 1 1000 | while read; do echo $REPLY | cat | cat | cat | cat; done | tail -2
999
1000

real    0m25.941s
user    0m0.000s
sys     0m0.000s

At least from the latter two runs Midipix seems to be at least 4.6x faster in forking (launching sub-processes).

BillyONeal · 2023-03-15T16:43:30Z

MSYS2 make is SLOW (~30min to build openssl compared to 5-6min in WSL2), if we can find out a way to use native make then it'd be great.

It seems unlikely that make is the source of the problem here rather than relative process creation costs on Linux vs. Windows and the scripts that comprise OpenSSL's build system wanting to spawn a zillion subprocesses.

sskras · 2023-03-15T20:21:58Z

I too think that it's fork() related (maybe something else along those lines).

Also I think @longnguyen2004 was referring not to the slowness of the make's implementation but rather to the overall result of the execution (as make should be doing a lot of forking too), if I guess the things right.

BillyONeal · 2023-03-15T20:24:38Z

I too think that it's fork() related (maybe something else along those lines).

Also I think @longnguyen2004 was referring not to the slowness of the make's implementation but rather to the overall result of the execution (as make should be doing a lot of forking too), if I guess the things right.

The problem is that the comparison is not vs. a native make implementation, it is vs. Linux, and the cited example is one of the "shell scripts that cause your CPU pain" posterchildren.

I'm not saying that a different make would make no difference, only that this isn't really evidence of that.

aminya · 2024-02-01T06:27:18Z

I want to add the deadlinks for Msys2 as another benefit of not using msys2 #36502

PhoebeHui assigned JackBoosY Jul 30, 2020

JackBoosY added the requires:discussion label Jul 30, 2020

JackBoosY assigned strega-nil Jul 30, 2020

JackBoosY assigned BillyONeal Aug 10, 2020

strega-nil removed their assignment Aug 21, 2020

linquize mentioned this issue Aug 23, 2020

Support a more smooth deployment of msys2 #8374

Closed

BillyONeal removed the requires:discussion label Aug 28, 2020

traversaro mentioned this issue Oct 2, 2020

Add boost-bind and libjpeg-turbo, bump vcpkg to commit from October 2020 and vendor custom port to avoid portaudio and ogre problem robotology/robotology-superbuild-dependencies-vcpkg#24

Merged

JackBoosY added the category:tool-update The issue is with build tool or build script, which requires update or should be executed correctly label Jan 6, 2021

hpjansson mentioned this issue Jul 1, 2022

Windows build with embedded GLib hpjansson/chafa#72

Open

Cheney-W assigned LilyWangLL and unassigned JackBoosY Dec 6, 2022

teo-tsirpanis mentioned this issue Nov 3, 2023

[libmagic] Update port to build with CMake. #34894

Closed

7 tasks

aminya mentioned this issue Feb 1, 2024

[msys2] dead msys2 links on Windows preventing any build #36502

Closed

Unix tools: move away from MSYS2 (if possible) #12636

Unix tools: move away from MSYS2 (if possible) #12636

Comments

longnguyen2004 commented Jul 29, 2020

linquize commented Jul 29, 2020

Neumann-A commented Jul 29, 2020

longnguyen2004 commented Jul 29, 2020

longnguyen2004 commented Jul 29, 2020

linquize commented Jul 29, 2020

longnguyen2004 commented Jul 29, 2020

MVoz commented Jul 31, 2020 • edited Loading

longnguyen2004 commented Jul 31, 2020 • edited Loading

longnguyen2004 commented Aug 1, 2020

linquize commented Aug 2, 2020 • edited Loading

longnguyen2004 commented Aug 2, 2020

linquize commented Aug 2, 2020

linquize commented Aug 2, 2020

Neumann-A commented Aug 2, 2020

longnguyen2004 commented Aug 2, 2020

MVoz commented Aug 2, 2020 • edited Loading

longnguyen2004 commented Aug 2, 2020

longnguyen2004 commented Aug 2, 2020 • edited Loading

longnguyen2004 commented Aug 8, 2020 • edited Loading

ras0219 commented Aug 10, 2020

longnguyen2004 commented Aug 11, 2020

longnguyen2004 commented Aug 11, 2020

JackBoosY commented Aug 11, 2020 • edited Loading

Neumann-A commented Aug 11, 2020

linquize commented Aug 11, 2020

longnguyen2004 commented Aug 13, 2020 • edited Loading

longnguyen2004 commented Aug 20, 2020 • edited Loading

mingwandroid commented Aug 21, 2020 • edited Loading

BillyONeal commented Aug 21, 2020

Neumann-A commented Aug 21, 2020

mingwandroid commented Aug 21, 2020 • edited Loading

linquize commented Aug 21, 2020 • edited Loading

MVoz commented Aug 22, 2020

longnguyen2004 commented Aug 22, 2020

MVoz commented Aug 22, 2020 • edited Loading

longnguyen2004 commented Aug 24, 2020

BillyONeal commented Aug 27, 2020

longnguyen2004 commented Aug 28, 2020

Luiz-Monad commented May 11, 2022 • edited Loading

hmoffatt commented Jun 7, 2022

dg0yt commented Jun 12, 2022 • edited Loading

sskras commented Mar 15, 2023 • edited Loading

BillyONeal commented Mar 15, 2023

sskras commented Mar 15, 2023

BillyONeal commented Mar 15, 2023

aminya commented Feb 1, 2024 • edited Loading

MVoz commented Jul 31, 2020 •

edited

Loading

longnguyen2004 commented Jul 31, 2020 •

edited

Loading

linquize commented Aug 2, 2020 •

edited

Loading

MVoz commented Aug 2, 2020 •

edited

Loading

longnguyen2004 commented Aug 2, 2020 •

edited

Loading

longnguyen2004 commented Aug 8, 2020 •

edited

Loading

JackBoosY commented Aug 11, 2020 •

edited

Loading

longnguyen2004 commented Aug 13, 2020 •

edited

Loading

longnguyen2004 commented Aug 20, 2020 •

edited

Loading

mingwandroid commented Aug 21, 2020 •

edited

Loading

mingwandroid commented Aug 21, 2020 •

edited

Loading

linquize commented Aug 21, 2020 •

edited

Loading

MVoz commented Aug 22, 2020 •

edited

Loading

Luiz-Monad commented May 11, 2022 •

edited

Loading

dg0yt commented Jun 12, 2022 •

edited

Loading

sskras commented Mar 15, 2023 •

edited

Loading

aminya commented Feb 1, 2024 •

edited

Loading