CMake Progress Marks Displayed Garbled in enable_pcon about msys2-runtime

[drankinatty]

What is strange is there will be lines of correct output surrounded by lines of garbled output, e.g.

[ 77%] Building C[  o7b9j%e]c t BCuMialkdeiFnigl eAsS/Mp womb-jdemcat- lCeMda-kfeaFdi[el .e8ds0i%/r]p/ wCm_-B/dummsi
aly-dslie6nd4g/ -oAfpStaM/d peoi.bcdjoie/rcpit/c CoC_-M/samdkskey/Fssi6rl4ce//sor/pptp2/w_pmci-ocdmomm/aop-nil/cepod
i--cfsoad_dkde/o.sudrbiclr/e/r/Cpd_2o/_umcbsolymesm_6om4na//tophpi.tcc/o.p_oidbcojou/
bpliec/od-osudbkl/es_rvc1/_rrpo2m__csohmimmo.nS/.poibcjo
_int64_ops/pico_int64_ops_aeabi.S.obj
[ 82%] Building ASM object CMakeFiles/pwm-dma-led-fade.dir/C_/msys64/opt/pico/pico-sdk/src/rp2_common/pico_float/flo
at_aeabi.S.obj
[ 83%] [ B8u5i%l]d inBgu iCl doibnjge cCt  oCbMjaekcetF iClMeask/epFwiml-edsm/ap-wlme-dd-mfaa-dlee.dd-ifra/dCe_./dmi
sry/sC6_4//mospyts/6p4i/coop/tp/ipcioc-os/dpki/csor-cs/drkp/2s_rcco/mrmpo2n_/cpoimcmoo_nf/lpoiacto/_ffllooaatt_/ifnl
iota_tr_omma.tch..ocb.jo
bj

The 82% line is fine, above and below are garbled. Strange.

[Biswa96]

Did you use ninja generator with cmake? That is -GNinja option with configure command. Is there any way others can reproduce the issue?

[drankinatty]

No, I didn't change a thing in the project. The only change to my system was the pacman update. I always use the Linux Makefile generator. I'll go boot windows, but if I recall correctly, I export the generator setting Linux Makefile from my .bashrc. (or /etc/profile -- can't recall which) What is bewildering is why is 82% perfectly fine, but the one before and one after all messed up?

[drankinatty]

Okay, booted into Win10 and the environment was set just as I recalled. Here are the last 5 lines in my .bashrc

## Raspberry Pico Build Env
export PICO_SDK_PATH=/opt/pico/pico-sdk
export PICO_EXAMPLES_PATH=/opt/pico/pico-examples
export PICO_PLAYGROUND_PATH=/opt/pico/pico-playground
export PICO_EXTRAS_PATH=/opt/pico/pico-extras
export CMAKE_GENERATOR=Unix Makefiles

Testing the environment is seeing the CMAKE_GENERATOR export:

$ echo $CMAKE_GENERATOR
Unix Makefiles

Yep. Now invoking cmake to setup a project and confirm:

$ 18:03 elite:~/.../pico/bld/i2c-mpu9250-multi> cm
PICO_SDK_PATH is C:/msys64/opt/pico/pico-sdk
PICO platform is rp2040.
-- The C compiler identification is GNU 10.1.0
-- The CXX compiler identification is GNU 10.1.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/msys64/mingw64/bin/arm-none-eabi-gcc.exe
Build type is Release
PICO target board is pico.
Using board configuration from C:/msys64/opt/pico/pico-sdk/src/boards/include/boards/pico.h
-- Found Python3: C:/msys64/mingw64/bin/python3.10.exe (found version "3.10.8") found components: Interpreter
TinyUSB available at C:/msys64/opt/pico/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support
 for USB.
cyw43-driver available at C:/msys64/opt/pico/pico-sdk/lib/cyw43-driver
lwIP available at C:/msys64/opt/pico/pico-sdk/lib/lwip
Using PICO_EXAMPLES_PATH from environment ('C:/msys64/opt/pico/pico-examples')
-- Configuring done
-- Generating done
-- Build files have been written to: C:/msys64/home/david/dev/arm/pico/bld/i2c-mpu9250-multi
18:03 elite:~/.../pico/bld/i2c-mpu9250-multi> l
total 1288
drwxr-xr-x 1 david None      0 Oct 17 18:03 .
drwxr-xr-x 1 david None      0 Oct 16 15:49 ..
drwxr-xr-x 1 david None      0 Oct 17 18:03 CMakeFiles
drwxr-xr-x 1 david None      0 Oct  7 13:15 elf2uf2
drwxr-xr-x 1 david None      0 Oct  7 13:14 generated
drwxr-xr-x 1 david None      0 Oct 17 18:03 pico-sdk
drwxr-xr-x 1 david None      0 Oct  7 13:15 pioasm
-rw-r--r-- 1 david None  20782 Oct 17 18:03 CMakeCache.txt
-rw-r--r-- 1 david None  93657 Oct 17 18:03 Makefile
-rw-r--r-- 1 david None   1858 Oct  7 13:14 cmake_install.cmake
-rw-r--r-- 1 david None  35012 Oct  7 13:16 i2c-mpu9250-multi.bin
-rw-r--r-- 1 david None 601837 Oct  7 13:16 i2c-mpu9250-multi.dis
-rw-r--r-- 1 david None  76532 Oct  7 13:16 i2c-mpu9250-multi.elf
-rw-r--r-- 1 david None 276887 Oct  7 13:16 i2c-mpu9250-multi.elf.map
-rw-r--r-- 1 david None  98558 Oct  7 13:16 i2c-mpu9250-multi.hex
-rw-r--r-- 1 david None  70144 Oct  7 13:16 i2c-mpu9250-multi.uf2

The output on the rebuild still goes nuts:

18:05 elite:~/.../pico/bld/i2c-mpu9250-multi> make -j4
Scanning dependencies of target bs2_default
[  1%] Performing build step for 'ELF[2 U F22%B]u ildP'er
forming build step for 'PioasmBuild'
[  5%] Built target bs2_default
Consolidate compiler generated dependencies of target elf2uf2
[  8%] Built target bs2_default_padded_checksummed_asm
Consolidate compiler generated dependencies of target pioasm
[ 50%] Building CXX object CMakeFiles/elf2uf2.dir/main.cpp.obj
[ 10%] Buildin[g  2C0X%X]  obBjueicltd iCnMga kCeXFXi loebsj/epcito aCsMma.kdeiFri/lmeasi/np.icopaps.mo.bdji
r/pio_assembler.cpp.obj
[ 30%] Building CXX object CMakeFiles/pioasm.dir/pio_disassembler.cpp.obj
[ 40%] Building CXX object CMakeFiles/pioasm.dir/gen/lexer.cpp.obj
[100%] Linking CXX executable elf2uf2.exe
[ 50%] Building CXX object CMakeFiles/pioasm.dir/gen/parser.cpp.obj
[100%] Built target elf2uf2
[  9%] No install step for 'ELF2UF2Build'
[ 60%] Building CXX object CMakeFiles/pioasm.dir/c_sdk_output.cpp.obj
[ 11%] Completed 'ELF2UF2Build'
[ 70%] Building CXX object CMakeFiles/pioasm.dir/python_output.cpp.obj
[ 18%] Built target ELF2UF2Build
[ 80%] Building CXX object CMakeFiles/pioasm.dir/hex_output.cpp.obj
Scanning dependencies of target i2c-mpu9250-multi
[ 90%] Building CXX object CMakeFiles/pioasm.dir/ada_output.cpp.obj
Consolidate compiler generated dependencies of target i2c-mpu9250-multi
[ [1 92%0]% ] BuBiulidlidnign gC  Co bojbejcetc tC MCaMkaekFeiFlielse/si/2ic2-cm-pmup9u295205-0m-umlutlit.id.idri/ri/2C
c_-/mmpsuy9s26540/-hmoumlet/id.acv.iodb/jd
ev[/ a2r2m%/]p ico/Bluiibl/dpiincgo _Cm poub.jce.cotb jCM
akeFiles/i2c-mpu9250-multi.dir/C_/msys64/home/david/dev/arm/pico/lib/pico_mpu_calibrate.c.obj
[100%] Linking CXX executable pioasm.exe
[ 23%] Building C object CMakeFiles/i2c-mpu9250-multi.dir/C_/msys64/home/david/dev/arm/pico/lib/pico_mpu_constants.c.ob
j
[ 25%] Building C object CMakeFiles/i2c-mpu9250-multi.dir/C_/msys64/home/dav[i d2/6d%e]v /aBrumi/lpdiicnog/ lCi bo/bpji
eccot_ mCpMua_kceoFnisloelse/.ic2.co-bmjpu
9250-multi.dir/C_/msys64/opt/pico/pico-sdk/src/rp2_common/pico_stdlib/stdlib.c.obj
[ 27%] Buil[d i2n9g% ]C  oBbujielcdti nCgM aCk eoFbijleecst/ iC2Mca-kmepFui9l2e5s0/-im2ucl-tmip.ud9i2r5/0C-_m/umlstyis.
6d4i/ro/pCt_//pmiscyos/6p4i/coop-ts/dpki/csor/cp/ircpo2-_scdokm/msornc//hrapr2d_wcaormem_ognp/ihoa/rgdpwiaor.ec_.colbaj
i
m/claim.c.obj
[ 30%] Building C object CMakeFiles/i2c-mpu9250-multi.dir/C_/msys64/opt/pico/pico-sdk/src/rp2_common/pico_platform/plat
form.c.obj
[ 31%] Building C object CMakeFiles/i[2 c3-3m%p]u 92B5u0i-lmduilntgi .Cd iorb/jCe_c/tm sCyMsa6k4e/Foiplte/sp/iic2oc/-pm
ipcuo9-2s5d0k-/msurlct/ir.pd2i_rc/oCm_m/omns/yhsa6r4d/woaprte/_psiycnoc//psiycnoc-.scd.ko/bsjr
c/rp2_common/hardware_irq/irq.c.obj
[ 34%] Building C object CMakeFiles/i2c-mpu9250-multi.dir/C_/msys64/opt/pico/pico-sdk/src/common/pico_sync/sem.c.obj
[ 36%] Buil[d i3n7g% ]C  oBbujielcdti nCgM aCk eoFbijleecst/ iC2Mca-kmepFui9l2e5s0/-im2ucl-tmip.ud9i2r5/0C-_m/umlstyis.
6d4i/ro/pCt_//pmiscyos/6p4i/coop-ts/dpki/csor/cp/iccoom-msodnk//psircco/_csoymnmco/nl/opcikc_oc_otriem.ec/.toibmje
.c.obj
[[1 0308%%]]  BuBiulitl d[ti an4rg0g %eC]t   oBpbuijioelacdstim n
CgM aCk eoFbijleecst/ iC2Mca-kmepFui9l2e5s0/-im2ucl-tmip.ud9i2r5/0C-_m/umlstyis.6d4i/ro/pCt_//pmiscyos/6p4i/coop-ts/dpk
i/csor/cp/iccoom-msodnk//psircco/_rtpi2m_ec/otmimmoeno/uhta_rhdewlapreer_.tci.moebrj/
timer.c.obj
[ 41%] No install step for 'PioasmBuild'
[ 43%] Building C object CMakeFiles/i2c-mpu9250-multi.dir/C_/msys64/opt/pico/pico-sdk/src/common/pico_util/datetime.c.o
bj
[ 44%] Building C object CMakeFiles/i2c-mpu9250-multi.dir/C_/msys64/[o p4t5/%p]i coB/upiilcdoi-nsgd kC/ sorbcj/eccotm m
CoMna/kpeiFciol_eust/iil2/cp-hmepaup9.2c5.0o-bmju
lti.dir/C_/msys64/opt/pico/pico-sdk/src/common/pico_util/queue.c.obj
[ 47%] Building C object CMakeFiles/i2c-mpu9250-multi.dir/C_/msys64/opt/pico/pico-sdk/src/common/pico_sync/mutex.c.obj
[ 48%] Completed 'PioasmBuild'
[ 50%] Building C object CMakeFiles/i2c-mpu9250-multi.dir/C_/msys64/opt/pico/pico-sdk/src/common/pico_sync/critical_sec
tion.c.obj
[ 51%] Building C object CMakeFiles/i2c-mpu9250-multi.dir/C_/msys64/opt/pico/[p i5c2o%-]s dkB/usirlcd/irnpg2 _Cc oombmj
oenc/th aCrMdawkaerFei_lueasr/ti/2uca-rmtp.uc9.2o5b0j-
multi.dir/C_/msys64/opt/pico/pico-sdk/src/rp2_common/pico_runtime/runtime.c.obj
[ 54%] Building C object CMakeFiles/i2c-mpu9250-multi.dir/C_/msys64/opt/pico/pico-sdk/src/rp2_common/hardware[_ c6l1o%c
]k s/Bculiolctk st.acr.goebtj
PioasmBuild
[ 62%] Building C object CMakeFiles/[i 26c3-%m]p u9B2u5i0l-dmiunlgt iC. doibrj/eCc_t/ mCsMyask6e[4F i/6lo5ep%st]// ipB2
iucci-olm/dppiuin9cg2o 5-C0s -domkbu/jlsetrcict./ drCiMpra2/kC_e_cF/oimmlsmeyossn/6/i4h2/acor-pdmtwp/aupr9ie2c_5op0/l-p
lmi/ucplolt-lis..dcdk.i/orsb/rjCc
_//rmps2y_sc6o4m/moopnt//hpaircdow/apriec_ov-rsedgk//vsrrecg/.rcp.2o_bcjo
mmon/hardware_watchdog/watchdog.c.obj
[ 66%] Building [C  [o6 b86j%9e]%c ]tB  uBCiuMliadlkideniFgni glC e Cso /boijb2ejcce-tcm tpC uMC9aM2ka5ek0Fe-iFmliuells
et/sii/.2idc2i-crm-/pmCup_9u/29m52s05y-0sm-6um4lu/tloitp.itd./idprii/rcC/o_C//_pm/ismcysosy-6ss46d/4ko//postpr/tcp//ipr
cipoc2/o_p/cipocimocm-oos-nds/kdh/kas/rrsdcrw/car/rpre2p__2xc_oo[s mcc7mo/0omx%nmo]/os pnBic/uc.piocil_.cdbooiob_nojpgt
r rCio nmot/bfbj/oepocrttir noCtmMf.a.ckc.e.oFobibjlj
e
s/i2c-mpu9250-multi.dir/C_/msys64/opt/pico/pico-sdk/src/rp2_common/pico_double/double_init_rom.c.obj
[ 72%] B[[ u7 i37l%5d]%i ]nB guB iuCli dloidbnijgne gcC t C o CboMjbaejkceetcF tiC lMCeaMska/ekiFe2iFcli-elmsep/sui/92i
2c25-c0m--pmmupu9ul29t52i05.-0dm-iumrlu/tlCit_.i/d.midsriy/rsC/6_C4/_/m/osmpystsy/6sp46i/4co/opo/tpp/tip/cipoci-ocs/odp
/kip/cisocr-ocs-/dsrkdp/k2s/_rsccro/cmr/mpro2pn_2/c_pocimocmmoom_nod/nop/uipbciloce_o/f_dlfooluaobtal/tef/_lfmolaaottah
_t.i_cnm.iaottb_hjr.
ocm..ocb.jo
bj
[ 76%] Building C o[b j7e7c%t]  CMBaukielFdiilnegs /CiX2Xc -ombpjue9c2t5 0C-MmaukletFii.ldeisr//iC2_c/-mmspyus96245/0o-
pmtu/lptiic.od/ipri/cCo_-/smdsky/ss6r4c//orppt2/_pciocmom/opni/cpoi-csod_km/aslrlco/cr/pp2i_ccoo_mmmaolnl/opci.cco._osb
tja
ndard_link/new_delete.cpp.obj
[ 79%] Buil[d i8n0g% ]C  oBbujielcdti nCgM aCk eoFbijleecst/ iC2Mca-kmepFui9l2e5s0/-im2ucl-tmip.ud9i2r5/0C-_m/umlstyis.
6d4i/ro/pCt_//pmiscyos/6p4i/coop-ts/dpki/csor/cp/ircpo2-_scdokm/msornc//pripc2o__csotmamnodna/rpdi_cloi_nskt/dbiion/asr
tyd_iion.fco..ocb.jo
bj
[ [8 18%3]% ] BuBiulidlidnign gC  Co bojbejcetc tC MCaMkaekFeiFlielse/si/2ic2-cm-pmup9u295205-0m-umlutlit.id.idri/rC/_C
/_m/smyssy6s46/4o/potp/tp/ipcioc/op/ipcioc-os-dskd/ks/rscr/cr/pr2p_2c_ocmommomno/np/ihcaor_dswtadrieo__iu2acr/ti/2sct.d
ci.oo_buja
rt.c.obj
[ 84%] Linking CXX executable i2c-mpu9250-multi.elf
[100%] Built target i2c-mpu9250-multi
18:05 elite:~/.../pico/bld/i2c-mpu9250-multi>

What else can I look at or provide to help? This absolutely did not start until the last pacman update. It seems like the compiler output just loses it's mind and randomly changes encoding or whatever causes the issue. I'm happy to check or get anything else you want to see. I'm a handy monkey on this end of the keyboard, and glad to help. Msys2 is an awsome enviironment, happy to do my part to help.

[Biswa96]

Try to use CMAKE_GENERATOR=Ninja

[drankinatty]

Okay, I used ninja and there wasn't garbled output -- but there wasn't much output to garble anyway compared to what make provides. Is there no way to make make play nice with the windows output? I'm a lot more comfortable with make than I am with ninja. make works, the output is just wonky. Worse case scenario I can live with the wonky output, but it seems like there should be a way to have it output cleanly.

The reason I say that is I have several old gtk+2 editors I build on windows, and I don't recall issues with output using make (of course cmake wasn't involved either). So I guess this is more an issue with having cmake progress output behave?

[Biswa96]

Try to use cmake --build <build_dir> --verbose or ninja -C <build_dir> --verbose command to show full output.

[drankinatty]

Tried ninja --verbose on Linux for a pico project and it blew up. It had no clue how to handle the picoasm syntax to build there. So I guess using ninja with pico is limited to Windows, or something went wrong with my setup. Will give it a go on Windows tomorrow. This is generally why I prefer make, it works seamlessly between Linux and Windows.

[Biswa96]

I can not provide the exact reason why the make output garbled up. I think it has to do something with msys2-runtime and how the console/pty/tty system differ between native and non-native Win32 programs. But I have tried some workaround with other project.

Either,
Set MSYS=disable_pcon environment variable before running any msys2 terminal. It can be set in Control Panel. This is required because recently msys2 enables conpty feature by default.

Or,
Set the job number to 1 i.e. make -j1

[drankinatty]

MSYS=disable_pcon is a winner. That is an easy enough workaround, and for the short rebuilds I did on Windows with make I didn't see any garbled output. make output is just so much cleaner than ninja (especially with ninja --verbose that dumps 1000 characters blocks of text). At least it is for me.

The beauty of msys2 is a seamless build environment between Linux and windows. It would lose that if the standard instructions were "prefer make on Linux" and "prefer ninja on Windows". Don't get me wrong, I'm not criticizing either one, both are good build systems, the point being made is you shouldn't have to learn both just to build on one OS or the other.

Whatever MSYS=disable_pcon relates to, seems to be at the center or causing the garbled text on Windows with cmake/make output. Thank you very much for pointing me to that option -- I likely wouldn't have found it and instead would have just gritted my teeth and use make dealing with the output.

I don't understand the windows console side enough to know why -j1 in a single job verses a parallel build would result in the console being confused and garbling output. At this point my builds for Pi/Pico or the TI/MSP432 are not large enough that the number of jobs makes much difference in compile time (the FLASH storage on most microcontrollers limit the project size)

If there is some way this issue can be fixed, I think it's worth the time to do (understanding with the workaround, other demands on developer time, this would be a low-priority, as the opportunity arises issue). However, with that said, if you guys have a need to close it, I'm satisfied I can make the work-arounds work. If I have time I'll try and look further into the code and what disable_pcon does and poke around and see if there is anything regarding whatever part of terminal output, code-page, encoding, whatever that may provide a solution -- I guess for the mintty output. Thank you again for the work-arounds.

[jeremyd2019]

This sounds like a bug in the enable_pcon path. @tyan0 is there enough here to figure out what's going on?

[tyan0]

I tried to reproduce the problem, however, I could not.

What I tried was:

wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/10.3-2021.10/gcc-arm-none-eabi-10.3-2021.10-win32.zip
unzip gcc-arm-none-eabi-10.3-2021.10-win32.zip
export PATH=/c/msys64/home/yano/gcc-arm-none-eabi-10.3-2021.10/bin:/c/msys64/home/yano/gcc-arm-none-eabi-10.3-2021.10/arm-none-eabi/bin:$PATH
git clone https://github.com/raspberrypi/pico-sdk.git
cd pico-sdk
git submodule update --init
mkdir build
cd build
cmake ..
cmake --build .
cd ../..
export PICO_SDK_PATH='c:\msys64\home\yano\pico-sdk'
git clone https://github.com/raspberrypi/pico-examples.git
cd pico-examples
mkdir build
cd build
cmake -G "Unix Makefiles" ..
make

Did I do differently something?

My environment is:

$ uname -a
MINGW64_NT-10.0-19045 HP-Z230 3.3.6-341.x86_64 2022-09-20 22:07 UTC x86_64 Msys
$ echo $MSYS

$

[tyan0]

I noticed the problem can be reproducible by 'make -j8' instead of just 'make'.
I will look into this problem. Please wait a while.

[dscho]

@tyan0 please think long and very hard how you can increase the lottery factor.

It is quite disconcerting that you are (comfortable to be?) the only one who is able to fix any pcon issues (of which there is a seemingly constant trickle, as you undoubtedly noticed, too). It points to overly fragile code that is hard to understand and an under-documented design and most likely lack of proper encapsulation.

I have raised this point before, multiple times, and instead of addressing this adequately, I see the opposite happening: even a patch I was able to craft was not met with any code review worth mentioning, but was instead replaced without any explanation whatsoever by a different patch.

Maybe you are eager to "keep everybody else out"? At least that is the most plausible explanation that comes to mind, if unwillingly. Surely you want to the pcon code to be fixable by more people than just yourself, and to communicate with others working on it, and to share your knowledge and ideas regarding the pcon code with other developers.

Needless to say that I hope that you are willing to fix this, because from my perspective that would need to be fixed to jive with the idea of Open Source.

[tyan0]

After various investigations, I concluded that this is not a pty bug, because this also happens in console (command prompt). Pty with pseudo console support provides for non-msys2 (win32 native) console apps the feature that they can work as if they are executed in console. Thanks to this feature, win32-native console apps such as gnuplot, win32-vim, dir /p in cmd.exe, etc. are work properly in pty (in mintty). Therefore, if an app has a problem in console, it is natural that the same problem happens in pty with pseudo console support.

The main cause of this problem is that a plural of outputs from parallel jobs in make are mixed each other in console. If the app is msys2 app (linked with msys-2.0.dll), write() to pty is guarded by mutex so that write() is done in atomic way. However, non-msys2 apps does not call write(), so mutex guard is not functional. Moreover, printf() of mingw-w64 calls fputc() byte by byte. https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/stdio/mingw_pformat.c#l459
Even worse, the console output is unbuffered. This causes mixture of multiple output from printf() character by character. In pty without pseudo console support (MSYS=disable_pcon case), named pipe, which is used for win32-native apps in pty, is full buffered, therefore the mixture problem does not occur.

These are the summary of my investigation.

[tyan0]

To verify the fact I had investigated, I applied a patch below for cmake. With this patch, the issue disappears.

diff --git a/Source/cmakemain.cxx b/Source/cmakemain.cxx
index f931e9d..4510aed 100644
--- a/Source/cmakemain.cxx
+++ b/Source/cmakemain.cxx
@@ -958,6 +958,7 @@ int do_open(int ac, char const* const* av)
 
 int main(int ac, char const* const* av)
 {
+  setvbuf(stdout, NULL, _IOLBF, BUFSIZ);
   cmSystemTools::EnsureStdPipes();
 
   // Replace streambuf so we can output Unicode to console
diff --git a/Source/kwsys/Terminal.c b/Source/kwsys/Terminal.c
index 39081a7..905467e 100644
--- a/Source/kwsys/Terminal.c
+++ b/Source/kwsys/Terminal.c
@@ -59,8 +59,16 @@ void kwsysTerminal_cfprintf(int color, FILE* stream, const char* format, ...)
   CONSOLE_SCREEN_BUFFER_INFO hOutInfo;
   HANDLE hOut = kwsysTerminalGetStreamHandle(stream);
   if (GetConsoleScreenBufferInfo(hOut, &hOutInfo)) {
-    pipeIsConsole = 1;
-    kwsysTerminalSetConsoleColor(hOut, &hOutInfo, stream, color);
+    DWORD mode;
+    GetConsoleMode(hOut, &mode);
+    if ((mode & ENABLE_VIRTUAL_TERMINAL_PROCESSING)
+        || SetConsoleMode(hOut, mode | ENABLE_VIRTUAL_TERMINAL_PROCESSING)) {
+      pipeIsVT100 = 1;
+      kwsysTerminalSetVT100Color(stream, color);
+    } else {
+      pipeIsConsole = 1;
+      kwsysTerminalSetConsoleColor(hOut, &hOutInfo, stream, color);
+    }
   }
 #endif
   if (!pipeIsConsole &&

The patch for Terminal.c is just needed because kwsysTerminalSetConsoleColor() calls fflush().

On the contrary, if setvbuf(stdout, NULL, _IONBF, 0) is embedded, the issue occurs even with MSYS=disable_pcon.

[[    77%%] ] ui[l3di2mnBug iCl doibnjeg cCt  objectc lcomcakske//hbeulloil_dr_esvusa/CrMiakaenFtsi/lCesM/ahellkoe_resFuisl.edsi/rb/uCi_/ldm_syvasr64/hioamnet/2.dyanir/o/poico-sdk/src/rp2_common/pico_stdlib/stdlib.c.obj
ther.c.obj

These facts confirm my findings.