WIP: Add Cygwin to CI

[btashton]

This is currently very much a WIP. Some of what is in the ci workflow file is working around issues where cibuild.sh does not support the Windows runners yet and will need to be moved over.

This also syncs the workflow file with the rest of the project.

[xiaoxiang781216]

@btashton can you split the Fetch-Source to another patch? so we can sync build.yaml with other project first, and then focus on Windows CI specific change.

[btashton]

@btashton can you split the Fetch-Source to another patch? so we can sync build.yaml with other project first, and then focus on Windows CI specific change.

Yeah I needed to test a modification for this repo, now that it is tested I can do that, but it will need to wait until tomorrow, it's late here.

[btashton]

I'm going to close this for now. We can always refer to it again later.

[btashton]

All right since we had another failure with Windows I will bring this back, but I think we should scope it to just run the sim build for now.
apache/nuttx#1672

[patacongo]

All right since we had another failure with Windows I will bring this back, but I think we should scope it to just run the sim build for now.
apache/incubator-nuttx#1672

Using sim will not catch breakage like that of PR #1450. That error is cause due to running and Windows native toolchain (in this case the the ARM embedded toolchain) to compile code under Cygwin.

I have been using sim with Cygwin and never experienced any problems.

[btashton]

Ok. I thought you had said something about not being about to use the native ARM Embedded toolchain with Cygwin, maybe I am missing something. Either way I'll make this is a priority since it is a big hole.

If I get this cleaned up next week (right now it has unrelated code changes) can you give me a little guidance on the toolchain.

[patacongo]

Ok. I thought you had said something about not being about to use the native ARM Embedded toolchain with Cygwin, maybe I am missing something. Either way I'll make this is a priority since it is a big hole.

Semantic problem. I am not being clear. The Windows native ARM cross-compiler toolchain -- like the ARM embedded toolchain. Versus a toolchain (like buildroot) that is compiled under Cygwin. And not the Windows native x86_64 toolchain. No problem with the last two. The word native was not clear in this context.

[patacongo]

I think you could replicate the problem with the sim platform if you used a Windows native GCC tool chain like MinGW. The pre-built Cygwin gcc is built under Cygwin and everything will use POSIX paths. That environment is indistiguishable for the most part from Linux. But MinGW (I think) will not understand POSIX paths and will general Windows paths. I have never experimented with that so I am pushing things.

[patacongo]

Here is the crux of the problem under Cygwin:

$ arm-none-eabi-gcc --print-file-name=libgcc.a
c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/libgcc.a
$ gcc --print-file-name=libgcc.a
/usr/lib/gcc/x86_64-pc-cygwin/9.3.0/libgcc.a

The latter is handled with no problem, the former fails when the make $(dir ...) command attempts to extract the path to libgcc.a. It needs a POSIX style path. 'cypath -u' can fix that.

[btashton]

@patacongo@v01d Getting this closer to being in a reasonable place, but it looks like there is an issue with make distclean

These folders are getting left behind:

arch/arm/include/board
arch/arm/include/chip

Here is a snip of the log:

2020-09-23T05:53:52.4368113Z + run_builds
2020-09-23T05:53:52.4368497Z + local ncpus
2020-09-23T05:53:52.4368876Z + case $os in
2020-09-23T05:53:52.4435993Z ++ grep -c '^processor' /proc/cpuinfo
2020-09-23T05:53:52.4529398Z + ncpus=2
2020-09-23T05:53:52.4529975Z + options+='-j 2'
2020-09-23T05:53:52.4537238Z + for build in $builds
2020-09-23T05:53:52.4538682Z + /cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/nuttx/tools/testbuild.sh -x -j 2 -e '-Wno-cpp -Werror' testlist/arm-12.dat
2020-09-23T05:53:52.6624240Z ====================================================================================
2020-09-23T05:53:52.6933227Z Configuration/Tool: b-l072z-lrwan1/adc,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
2020-09-23T05:53:52.8755745Z ------------------------------------------------------------------------------------
2020-09-23T05:53:52.8756749Z Cleaning...
2020-09-23T05:53:52.8763608Z Configuring...
2020-09-23T05:54:05.8825442Z Disabling CONFIG_TOOLCHAIN_WINDOWS
2020-09-23T05:54:05.9027901Z Enabling CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
2020-09-23T05:54:12.0438219Z Building NuttX...
2020-09-23T05:57:29.1106768Z Normalize b-l072z-lrwan1/adc
2020-09-23T05:57:50.9600085Z ====================================================================================
2020-09-23T05:57:50.9914331Z Configuration/Tool: b-l072z-lrwan1/nsh,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
2020-09-23T05:57:51.1640490Z ------------------------------------------------------------------------------------
2020-09-23T05:57:51.1641713Z Cleaning...
2020-09-23T05:58:18.9865401Z On branch master
2020-09-23T05:58:18.9867462Z Your branch is up to date with 'origin/master'.
2020-09-23T05:58:18.9870101Z 2020-09-23T05:58:18.9872698Z Ignored files:
2020-09-23T05:58:18.9885491Z (use "git add -f <file>..." to include in what will be committed)
2020-09-23T05:58:18.9900250Z arch/arm/include/board
2020-09-23T05:58:18.9909236Z arch/arm/include/chip
2020-09-23T05:58:18.9914370Z 2020-09-23T05:58:18.9915972Z nothing to commit, working tree clean
2020-09-23T05:58:19.2661926Z ##[error]Process completed with exit code 1.

[protobits]

Great work, it will saves time in the future avoiding build breaks.

I'm not really familiar with cygwin to understand the breakage. But I suspect it has something to do with the script that handle symlinks. @patacongo any ideas?

[patacongo]

Great work, it will saves time in the future avoiding build breaks.

I'm not really familiar with cygwin to understand the breakage. But I suspect it has something to do with the script that handle symlinks. @patacongo any ideas?

I never noticed, but yes it is a real problem. I have several old board and and chip directories. We need to open an issue. These two lines in arch/arm/src/Makefile (and other arch Makefiles) are not working under cygwin:

 $(Q) $(DIRUNLINK) $(ARCH_SRC)/board
$(Q) $(DIRUNLINK) $(ARCH_SRC)/chip

Cygwin supports is own style of symbolic links and these are used EXCEPT for the case where a Windows native toolchain is used such as the popular (https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm).

Those are Window native tools and cannot follow non-standard Cygwin symbolic links so in this case, the tools/dirlinks.sh script does a full directory copy and the corresponding unlink script does a directory removal.

Without knowing more, it looks like the DIRUNLINK is failing to remove the Cygwin symbolic link or the copied directory.

[patacongo]

The dir unlink script seems to be working fine, however (at least using a relative path):

$ find . -name chip
./arch/arm/include/chip
./arch/arm/src/chip
./arch/z80/include/chip
./include/arch/chip
$ tools/unlink.sh ./arch/z80/include/chip
$ find . -name chip
./arch/arm/include/chip
./arch/arm/src/chip
./include/arch/chip

[patacongo]

Oops.. didn't mean to close.

[patacongo]

@v01d@btashton I have analyzed this. It is due to changes make in the build system that were never verified on Cygwin. I have documented the problem in apache/nuttx#1880

I don't have any good solution other than reverting some changes recently made to the Makefile.

[btashton]

@patacongo I have to step away for the day (new job so back to evenings, mornings and weekends) but I appreciate you digging into it and I'll do what I can to make sure we have the protections in place via CI going forward. MinGW will also need to be added at some point. I suspect that will actually be easier since the runners are already configured with the core packages.

[patacongo]

@patacongo I have to step away for the day (new job so back to evenings, mornings and weekends) but I appreciate you digging into it and I'll do what I can to make sure we have the protections in place via CI going forward. MinGW will also need to be added at some point. I suspect that will actually be easier since the runners are already configured with the core packages.

The good news is that your CI changes work! The correctly caught an error introduced into the build system.

[btashton]

I just tweaked the workflow to so we can get a full run with all of the errors. I looks like there are still a couple issues with the build we need to address, but @liuguo09 patch did fix the folder issue.

[btashton]

@patacongo @xiaoxiang78121 The build is taking a long time, but I am seeing a handful of different classes of errors. What do you think about enabling the cygwin CI, but making it not fail the workflow. That way we can more easily validate the fixes, but also not fail unrelated PRs?

https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error

[btashton]

Looks cpp related

====================================================================================
Configuration/Tool: nucleo-144/f722-nsh,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
------------------------------------------------------------------------------------
Cleaning...
Configuring...
Disabling CONFIG_TOOLCHAIN_WINDOWS
Enabling CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
.config:1432:warning: override: ARMV7M_TOOLCHAIN_GNU_EABIL changes choice state
Building NuttX...
libxx_cxa_atexit.cxx:40:10: fatal error: nuttx/config.h: No such file or directory
40 | #include <nuttx/config.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.
make[1]: *** [Makefile:84: libxx_cxa_atexit.o] Error 1
libxx_eabi_atexit.cxx:40:10: fatal error: nuttx/config.h: No such file or directory
40 | #include <nuttx/config.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.

make distclean is then leaving deps around

 ====================================================================================
Configuration/Tool: nucleo-144/f746-evalos,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
------------------------------------------------------------------------------------
Cleaning...
On branch master
Your branch is up to date with 'origin/master'.
Ignored files:
(use "git add -f <file>..." to include in what will be committed)
system/nsh/Make.dep
system/readline/Make.dep

[patacongo]

These all look like toolchain-related issues? Which toolchain are you using? I recommend the ARM embedded toolchain which is a windows native toolchain. All of the problems that I see could be explained if CONFIG_CYGWIN_WINTOOL were not set:

The -I and -isystem arguments would be wrong in this case:

ERROR: arm-none-eabi-gcc failed: 1
command: arm-none-eabi-gcc -MT ./cle.cygdrive.d.a.incubator-nuttx-testing.incubator-nuttx-testing.apps.system.cle.o -M '-fno-builtin' '-Wall' '-Wstrict-prototypes' '-Wshadow' '-Wundef' '-g' '-mcpu=cortex-m7' '-mthumb' '-mfloat-abi=soft' '-isystem' '/cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/nuttx/include' '-D__KERNEL__' '-Wno-cpp' '-Werror' '-pipe' '-I' '/cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/apps/graphics/lvgl' '-I' '/cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/apps/graphics/lvgl/lvgl' '-I' '/cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/apps/include' ./cle.c

The following error often happens in that case:

 make[1]: *** [Makefile:63: /cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/apps/platform_depend] Error 2
./cle.c:40:10: fatal error: nuttx/config.h: No such file or directory
40 | #include <nuttx/config.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.

That is because the windows toolchain cannot follow the cygwin paths.

Can you verify that CONFIG_CYGWIN_WINTOOL is selected after running make olddefconfig? It will not be selected in the defconfig file, but should be selected if during make olddefconfig if the correct toolchain is selected. See arch/arm/src/armv7-m/Kconfig

[patacongo]

The following error often happens in that case:

 make[1]: *** [Makefile:63: /cygdrive/d/a/incubator-nuttx-testing/incubator-nuttx-testing/apps/platform_depend] Error 2
./cle.c:40:10: fatal error: nuttx/config.h: No such file or directory
40 | #include <nuttx/config.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.

That is because the windows toolchain cannot follow the cygwin paths.

This also can occur if the links are Cygwin symbolic links. In that case, the Windows toolchain cannot follow those symbolic links.

[patacongo]

Aha... This is probably the problem:

 Configuring...
Disabling CONFIG_TOOLCHAIN_WINDOWS
Enabling CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
.config:1350:warning: override: ARMV7M_TOOLCHAIN_GNU_EABIL changes choice state
Building NuttX...

That will need to be CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIW for the Windows native toolchin. CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL selects the Linux toolchain (or a custom toolchain built under Cygwin, not a native toolchain).

[patacongo]

Aha... This is probably the problem:

 Configuring...
Disabling CONFIG_TOOLCHAIN_WINDOWS
Enabling CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
.config:1350:warning: override: ARMV7M_TOOLCHAIN_GNU_EABIL changes choice state
Building NuttX...

That will need to be CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIW for the Windows native toolchin. CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL selects the Linux toolchain (or a custom toolchain built under Cygwin, not a native toolchain).

And this seems to be because the test list you are using specifies the Linux toolchain:

====================================================================================
Configuration/Tool: b-l072z-lrwan1/nsh,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
------------------------------------------------------------------------------------
Cleaning...
Configuring...
Disabling CONFIG_TOOLCHAIN_WINDOWS
Enabling CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL
Building NuttX...
Normalize b-l072z-lrwan1/nsh
====================================================================================

Unfortunately, you cannot re-use the Linux test lists for Cygwin. The test lists need CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIW if you are using the ARM embedded windows native toolchain.

[patacongo]

Looks cpp related

It is, but only because the Windows cpp can't follow the symbolic links and cannot handle the POSIX-style include paths.

[btashton]

Ah you are right. I'll see if I can fix that, we are unfortunately using -c for two different things in cibuild.sh and testbuild.sh so I'll have to sort that as well

[patacongo]

In my original test lists (https://bitbucket.org/nuttx/tools/src/master/buildtest/armlist.template) I specified the toolchain as CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIx. I then changed the x to either W or L using sed.

[btashton]

There are also errors in the sim build
https://github.com/apache/incubator-nuttx-testing/pull/39/checks?check_run_id=1173303475

[patacongo]

This is probably real code breakage. Again, it is a screw-up in include paths:

/usr/include/cygwin/socket.h:27:8: error: redefinition of 'struct sockaddr'
27 | struct sockaddr {
| ^~~~~~~~
In file included from /usr/include/w32api/winsock2.h:57,
from sim/up_wpcap.c:48:
/usr/include/w32api/psdk_inc/_ip_types.h:70:8: note: originally defined here
70 | struct sockaddr {
| ^~~~~~~~
In file included from /usr/include/sys/socket.h:13,
from /usr/include/cygwin/in.h:21,
from /usr/include/netinet/in.h:12,
from sim/up_wpcap.c:57:
/usr/include/cygwin/socket.h:39:8: error: redefinition of 'struct sockaddr_storage'
39 | struct sockaddr_storage {
| ^~~~~~~~~~~~~~~~
In file included from sim/up_wpcap.c:48:
/usr/include/w32api/winsock2.h:269:10: note: originally defined here
269 | struct sockaddr_storage {
| ^~~~~~~~~~~~~

sim_wcap.c hasn't been build in ages. It is mixing Cygwin and Windows socket definitions. As I recall, this is a host file and, hence should be using all Windows definitions.

The likelihood that this still works (even if built correctly) is low.

I will look into this too.

[patacongo]

This is probably real code breakage. Again, it is a screw-up in include paths:

/usr/include/cygwin/socket.h:27:8: error: redefinition of 'struct sockaddr'
27 | struct sockaddr {
| ^~~~~~~~
In file included from /usr/include/w32api/winsock2.h:57,
from sim/up_wpcap.c:48:
/usr/include/w32api/psdk_inc/_ip_types.h:70:8: note: originally defined here
70 | struct sockaddr {
| ^~~~~~~~
In file included from /usr/include/sys/socket.h:13,
from /usr/include/cygwin/in.h:21,
from /usr/include/netinet/in.h:12,
from sim/up_wpcap.c:57:
/usr/include/cygwin/socket.h:39:8: error: redefinition of 'struct sockaddr_storage'
39 | struct sockaddr_storage {
| ^~~~~~~~~~~~~~~~
In file included from sim/up_wpcap.c:48:
/usr/include/w32api/winsock2.h:269:10: note: originally defined here
269 | struct sockaddr_storage {
| ^~~~~~~~~~~~~

sim_wcap.c hasn't been build in ages. It is mixing Cygwin and Windows socket definitions. As I recall, this is a host file and, hence should be using all Windows definitions.

The likelihood that this still works (even if built correctly) is low.

I will look into this too.

This was, I am pretty sure, introduced with commit: 8ce0ff5ce44416511be343c842c8d714687182cf with this change:

diff --git a/arch/sim/src/sim/up_wpcap.c b/arch/sim/src/sim/up_wpcap.c
index ef7b4b3a0c..a15421e80c 100644
--- a/arch/sim/src/sim/up_wpcap.c
+++ b/arch/sim/src/sim/up_wpcap.c
@@ -55,6 +55,8 @@
#include <netinet/in.h>
+#include "up_internal.h"
+
/****************************************************************************
* Pre-processor Definitions
****************************************************************************/

up_internal.h includes:

 47 # include <sys/types.h>
48 # include <stdbool.h>
49 # include <netinet/in.h>

And netinet/in.h includes:

 46 #include <sys/types.h>
47 #include <sys/socket.h>
48 #include <stdint.h>

Which is where the collision error is introduced since up_wpcap.c includes winsock2.h already. The solution: Revert that single file change.

[patacongo]

@btashton PR apache/nuttx#1903 solves this build problem.

[btashton]

Thanks Greg, I'll check it out shortly. I am getting my local windows environment back up to make this testing a little quicker.

[btashton]

@patacongo I ran the Cygwin build locally and when I try to run the executable it crashes. Strace shows this, any idea what is going on? (nettest and nsh had the same result)

--- Process 1892 created
--- Process 1892 loaded C:\Windows\System32\ntdll.dll at 00007ffbca2c0000
--- Process 1892 loaded C:\Windows\System32\kernel32.dll at 00007ffbca070000
--- Process 1892 loaded C:\Windows\System32\KernelBase.dll at 00007ffbc75e0000
--- Process 1892 thread 5812 created
--- Process 1892 loaded C:\Windows\System32\ws2_32.dll at 00007ffbc9ad0000
--- Process 1892 loaded C:\Windows\System32\rpcrt4.dll at 00007ffbc8370000
--- Process 1892 loaded C:\Windows\System32\IPHLPAPI.DLL at 00007ffbc6680000
--- Process 1892 thread 4800 created
--- Process 1892 thread 9592 created
--- Process 1892 loaded C:\tools\cygwin\bin\cygwin1.dll at 0000000180040000
--- Process 1892 loaded C:\tools\cygwin\bin\cygz.dll at 00000003fbf80000
5 5 [main] nuttx (1892) **********************************************
369 374 [main] nuttx (1892) Program name: C:\tools\cygwin\home\btashton\sources\nuttx\nuttx.exe (windows pid 1892)
241 615 [main] nuttx (1892) OS version: Windows NT-10.0
277 892 [main] nuttx (1892) **********************************************
--- Process 1892 loaded C:\Windows\System32\advapi32.dll at 00007ffbc90e0000
--- Process 1892 loaded C:\Windows\System32\msvcrt.dll at 00007ffbc99d0000
--- Process 1892 loaded C:\Windows\System32\sechost.dll at 00007ffbc9f30000
--- Process 1892 loaded C:\Windows\System32\cryptbase.dll at 00007ffbc6ba0000
--- Process 1892 loaded C:\Windows\System32\bcryptprimitives.dll at 00007ffbc73c0000
27939 28831 [main] nuttx (1892) sigprocmask: 0 = sigprocmask (0, 0x0, 0x180320DD0)
1040 29871 [main] nuttx (1892) open_shared: name shared.5, n 5, shared 0x180030000 (wanted 0x180030000), h 0x10C, *m 6
243 30114 [main] nuttx (1892) user_heap_info::init: heap base 0x800000000, heap top 0x800000000, heap size 0x20000000 (536870912)
251 30365 [main] nuttx (1892) open_shared: name S-1-5-21-809113384-3503045568-2100469263-1000.1, n 1, shared 0x180020000 (wanted 0x180020000), h 0x108, *m 6
238 30603 [main] nuttx (1892) user_info::create: opening user shared for 'S-1-5-21-809113384-3503045568-2100469263-1000' at 0x180020000
250 30853 [main] nuttx (1892) user_info::create: user shared version AB1FCCE8
280 31133 [main] nuttx (1892) fhandler_pipe::create: name \\.\pipe\cygwin-c3851c815b7231fc-1892-sigwait, size 11440, mode PIPE_TYPE_MESSAGE
315 31448 [main] nuttx (1892) fhandler_pipe::create: pipe read handle 0x120
277 31725 [main] nuttx (1892) fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-c3851c815b7231fc-1892-sigwait
1715 33440 [main] nuttx (1892) fhandler_pipe::create: pipe write handle 0x124
1706 35146 [main] nuttx (1892) dll_crt0_0: finished dll_crt0_0 initialization
--- Process 1892 thread 9836 created
6195 41341 [main] nuttx (1892) set_signal_mask: setmask 0, newmask FFFFFFFFFFFEFEFF, mask_bits 0
1370 42711 [main] nuttx (1892) pthread_sigmask: 0 = pthread_sigmask(0, 0xFFFFCA30, 0xFFFFCA38)
1850 44561 [main] nuttx (1892) set_signal_mask: setmask FFFFFFFFFFFEFEFF, newmask 0, mask_bits FFFFFFFFFFFEFEFF
1851 46412 [sig] nuttx (1892) wait_sig: entering ReadFile loop, my_readsig 0x120, my_sendsig 0x124
2396 48808 [main] nuttx (1892) pthread_sigmask: 0 = pthread_sigmask(0, 0xFFFFCA28, 0x0)
6271 55079 [main] nuttx (1892) set_signal_mask: setmask 0, newmask FFFFFFFFFFFEFEFF, mask_bits 0
4638 59717 [main] nuttx (1892) pthread_sigmask: 0 = pthread_sigmask(0, 0xFFFFC9C0, 0xFFFFC9C8)
3305 63022 [main] nuttx (1892) set_signal_mask: setmask FFFFFFFFFFFEFEFF, newmask 0, mask_bits FFFFFFFFFFFEFEFF
3421 66443 [main] nuttx (1892) pthread_sigmask: 0 = pthread_sigmask(0, 0xFFFFC9B8, 0x0)
70955 [main] nuttx (1892) C:\tools\cygwin\home\btashton\sources\nuttx\nuttx.exe: *** fatal error - Internal error: Out of memory for new path buf.
4512 70955 [main] nuttx (1892) C:\tools\cygwin\home\btashton\sources\nuttx\nuttx.exe: *** fatal error - Internal error: Out of memory for new path buf.
75682 [main] nuttx (1892) cygwin_exception::open_stackdumpfile: Dumping stack trace to nuttx.exe.stackdump
4727 75682 [main] nuttx (1892) cygwin_exception::open_stackdumpfile: Dumping stack trace to nuttx.exe.stackdump
70579 146261 [main] nuttx (1892) proc_terminate: nprocs 0
470 146731 [main] nuttx (1892) proc_terminate: leaving
$ 2490 152125 [main] nuttx (1892) pinfo::exit: Calling ExitProcess n 0x1, exitcode 0x100```

[btashton]

@patacongo I see this is mentioned in the README sorry.

Hmm I take that back. It is called out in the README, but the fix does not seem to work.
https://github.com/apache/incubator-nuttx/blob/09a2c37daf99649c1f9d1c88269725318707518b/boards/sim/sim/sim/README.txt#L253

[btashton]

sim:module sim:tcpblaster sim:dsptest sim:sotest all failed. A couple others failed as well but that was due to not having patch installed. I'll add that to the required Cygwin tools.

The ARM builds all passed though which is good.

2.5hr is really not great. I'm wondering why this is sooo slow and if there is something we can do about it.

[xiaoxiang781216]

no difference between Linux and Cygwin?

[xiaoxiang781216]

How about we remove CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIx from all datalist?