WIP: Add Cygwin to CI #39

btashton · 2020-04-28T06:29:22Z

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 · 2020-04-28T06:37:19Z

@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 · 2020-04-28T07:19:41Z

@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 · 2020-08-28T19:05:28Z

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

btashton · 2020-08-30T20:48:14Z

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 · 2020-08-30T21:22:25Z

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 · 2020-08-30T21:27:33Z

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 · 2020-08-30T21:31:31Z

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 · 2020-08-30T21:40:40Z

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 · 2020-08-30T22:06:40Z

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 · 2020-09-23T06:03:32Z

@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 · 2020-09-23T13:23:21Z

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 · 2020-09-23T13:50:56Z

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 · 2020-09-23T13:53:49Z

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 · 2020-09-23T13:54:05Z

Oops.. didn't mean to close.

patacongo · 2020-09-23T14:05:55Z

See Issue apache/nuttx#1880

patacongo · 2020-09-23T15:30:45Z

@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 · 2020-09-23T15:40:52Z

@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 · 2020-09-23T18:21:26Z

@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 · 2020-09-27T18:09:48Z

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 · 2020-09-27T19:22:58Z

@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 · 2020-09-27T19:36:35Z

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 · 2020-09-27T19:44:49Z

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 · 2020-09-27T19:46:09Z

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 · 2020-09-27T19:51:02Z

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 · 2020-09-27T19:56:46Z

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 · 2020-09-27T19:59:26Z

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 · 2020-09-27T20:00:22Z

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 · 2020-09-27T20:08:50Z

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 · 2020-09-27T20:32:40Z

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

patacongo · 2020-09-27T20:42:49Z

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 · 2020-09-27T20:54:47Z

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 · 2020-09-27T21:17:48Z

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

btashton · 2020-09-27T21:25:12Z

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 · 2020-09-28T00:59:59Z

@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 · 2020-09-28T01:03:13Z

@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

Signed-off-by: Brennan Ashton <[email protected]>

btashton · 2020-09-28T04:38:06Z

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 · 2020-09-28T12:51:17Z

cibuild.sh

@@ -391,6 +420,9 @@ function run_builds {
    Linux)
      ncpus=`grep -c ^processor /proc/cpuinfo`
      ;;
+    Cygwin)
+      ncpus=`grep -c ^processor /proc/cpuinfo`


no difference between Linux and Cygwin?

xiaoxiang781216 · 2020-09-28T12:51:36Z

testlist/arm-12-win.dat

@@ -0,0 +1,5 @@
+/arm/stm32f0l0g0,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIW


How about we remove CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIx from all datalist?

btashton force-pushed the windows-ci branch from b1771fa to aa422be Compare April 28, 2020 06:32

btashton force-pushed the windows-ci branch from aa422be to 62f2311 Compare April 28, 2020 06:45

btashton force-pushed the windows-ci branch from 62f2311 to 2c90ff7 Compare April 28, 2020 07:33

btashton closed this Aug 28, 2020

btashton reopened this Aug 30, 2020

btashton force-pushed the windows-ci branch 9 times, most recently from bb42d72 to 2bf71c6 Compare September 23, 2020 05:45

patacongo closed this Sep 23, 2020

patacongo reopened this Sep 23, 2020

patacongo mentioned this pull request Sep 23, 2020

Cygwin directories not being cleaned apache/nuttx#1880

Closed

btashton force-pushed the windows-ci branch 2 times, most recently from 1ac2d95 to 051ef3f Compare September 27, 2020 18:08

Enable Cygwin build

1efd200

Signed-off-by: Brennan Ashton <[email protected]>

btashton force-pushed the windows-ci branch from 051ef3f to 1efd200 Compare September 28, 2020 01:43

ci: Handle case where prebuilt was cached but brew install binutils

7b9e06d

btashton force-pushed the windows-ci branch from 68b6c91 to 7b9e06d Compare September 28, 2020 05:34

xiaoxiang781216 reviewed Sep 28, 2020

View reviewed changes

		@@ -0,0 +1,5 @@
		/arm/stm32f0l0g0,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIW

WIP: Add Cygwin to CI #39

Are you sure you want to change the base?

WIP: Add Cygwin to CI #39

Conversation

btashton commented Apr 28, 2020

xiaoxiang781216 commented Apr 28, 2020

btashton commented Apr 28, 2020

btashton commented Aug 28, 2020

btashton commented Aug 30, 2020 • edited Loading

patacongo commented Aug 30, 2020

btashton commented Aug 30, 2020

patacongo commented Aug 30, 2020 • edited Loading

patacongo commented Aug 30, 2020

patacongo commented Aug 30, 2020

btashton commented Sep 23, 2020 • edited Loading

protobits commented Sep 23, 2020

patacongo commented Sep 23, 2020

patacongo commented Sep 23, 2020 • edited Loading

patacongo commented Sep 23, 2020

patacongo commented Sep 23, 2020

patacongo commented Sep 23, 2020 • edited Loading

btashton commented Sep 23, 2020

patacongo commented Sep 23, 2020

btashton commented Sep 27, 2020

btashton commented Sep 27, 2020

btashton commented Sep 27, 2020

patacongo commented Sep 27, 2020

patacongo commented Sep 27, 2020

patacongo commented Sep 27, 2020

patacongo commented Sep 27, 2020

patacongo commented Sep 27, 2020

btashton commented Sep 27, 2020

patacongo commented Sep 27, 2020

btashton commented Sep 27, 2020

patacongo commented Sep 27, 2020 • edited Loading

patacongo commented Sep 27, 2020

patacongo commented Sep 27, 2020

btashton commented Sep 27, 2020

btashton commented Sep 28, 2020

btashton commented Sep 28, 2020 • edited Loading

btashton commented Sep 28, 2020

xiaoxiang781216 Sep 28, 2020

Choose a reason for hiding this comment

xiaoxiang781216 Sep 28, 2020

Choose a reason for hiding this comment

btashton commented Aug 30, 2020 •

edited

Loading

patacongo commented Aug 30, 2020 •

edited

Loading

btashton commented Sep 23, 2020 •

edited

Loading

patacongo commented Sep 23, 2020 •

edited

Loading

patacongo commented Sep 23, 2020 •

edited

Loading

patacongo commented Sep 27, 2020 •

edited

Loading

btashton commented Sep 28, 2020 •

edited

Loading