Cygwin Build Broken

[patacongo]

PR #1450 broke the Cygwin build and it is still broken in the current master. Consider this:

$ tools/configure.sh -c nucleo-l476rg:nsh
$ make -j V=1

Results in:

arm-none-eabi-ld --entry=__start -nostartfiles -nodefaultlibs -g -T "D:\Spuda\Documents\projects\nuttx\master\nuttx_fork\boards\arm\stm32l4\nucleo-l476rg\scripts\l476rg.ld"  -L"D:\Spuda\Documents\projects\nuttx\master\nuttx_fork\staging" -L"D:\Spuda\Documents\projects\nuttx\master\nuttx_fork\arch\arm\src\board" -L "c:/ ./ (x86)/ ./ ./ embedded/ 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v7e-m/nofp/" -L "c:/ ./ (x86)/ ./ ./ embedded/ 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/" \
        -o "D:\Spuda\Documents\projects\nuttx\master\nuttx_fork\nuttx.exe"   \
        --start-group -lsched -ldrivers -lboards -lc -lmm -larch -lxx -lapps -lfs -lbinfmt -lboard -lgcc -lm --end-group
C:\Program Files (x86)\GNU Tools ARM Embedded\9 2019-q4-major\bin\arm-none-eabi-ld.exe: cannot find -lgcc
C:\Program Files (x86)\GNU Tools ARM Embedded\9 2019-q4-major\bin\arm-none-eabi-ld.exe: cannot find -lm
make[1]: *** [Makefile:172: nuttx.exe] Error 1

Trying again with a different configuration, no -j and no V=1 gives me the same error:

$ make distclean
$ tools/configure.sh -c stm32f4discovery:nsh
...
LD: nuttx
C:\Program Files (x86)\GNU Tools ARM Embedded\9 2019-q4-major\bin\arm-none-eabi-ld.exe: cannot find -lgcc
C:\Program Files (x86)\GNU Tools ARM Embedded\9 2019-q4-major\bin\arm-none-eabi-ld.exe: cannot find -lm
make[1]: *** [Makefile:172: nuttx.exe] Error 1

The problem is due to this commit:

commit 4910d43ab0fc360dbddb1f8a31db2a3ee383b46d
Author: Xiang Xiao <xiaoxiang@xiaomi.com>
Date:   Wed Jul 15 20:51:26 2020 +0800

    build: Move the toolchain library setting to the common place

    so all boards support C++ automatically

Commit 4910d43 adds logic like the following to all Toolchain.defs files:

+
+# Add the builtin library
+
+EXTRA_LIBS += -lgcc
+EXTRA_LIBPATHS += -L "${dir ${shell $(CC) $(ARCHCPUFLAGS) --print-file-name=libgcc.a}}"
+
+ifneq ($(CONFIG_LIBM),y)
+  EXTRA_LIBS += -lm
+  EXTRA_LIBPATHS += -L "${dir ${shell $(CC) $(ARCHCPUFLAGS) --print-file-name=libm.a}}"
+endif
+
+ifeq ($(CONFIG_CXX_LIBSUPCXX),y)
+  EXTRA_LIBS += -lsupc++
+  EXTRA_LIBPATHS += -L "${dir ${shell $(CC) $(ARCHCPUFLAGS) --print-file-name=libsupc++.a}}"
+endif

But look what happens 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

$ dir `arm-none-eabi-gcc --print-file-name=libgcc.a`
dir: cannot access 'c:/program': No such file or directory
dir: cannot access 'files': No such file or directory
dir: cannot access '(x86)/gnu': No such file or directory
dir: cannot access 'arm': No such file or directory
dir: cannot access 'embedded/9': No such file or directory
dir: cannot access '2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/libgcc.a'$'\r': No such file or directory
...

Broken!

[patacongo]

This problem really applies to any path that contains spaces or any unusual characters. It breaks on Cygwin because of the extensive use of unusual characters under Windows. But it is equally broken on other platforms.

We must not release code with this showstopping bug in it.

[protobits]

I added this to the next release milestone so that it becomes a blocker for next release

[protobits]

(assuming 10.0 will be next, we can rename it to whatever we think it should be)

[patacongo]

This has been broken since July 15. This is why is it essential to get at least one Cygwin build using a Windows native toolchain into the PR checks.

[patacongo]

$ dir arm-none-eabi-gcc --print-file-name=libgcc.a
dir: cannot access 'c:/program': No such file or directory
dir: cannot access 'files': No such file or directory
dir: cannot access '(x86)/gnu': No such file or directory
dir: cannot access 'arm': No such file or directory
dir: cannot access 'embedded/9': No such file or directory
dir: cannot access '2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/libgcc.a'$'\r': No such file or directory
...

Just as a clarification. The above uses the command 'dir' which is not the same as the make 'dir' command. So lets do things right:

diff --git a/arch/arm/src/armv7-m/Toolchain.defs b/arch/arm/src/armv7-m/Toolchain.defs
index 74e071bb0f..4d3b80c42f 100644
--- a/arch/arm/src/armv7-m/Toolchain.defs
+++ b/arch/arm/src/armv7-m/Toolchain.defs
@@ -155,6 +155,9 @@ OBJDUMP = $(CROSSDEV)objdump
 EXTRA_LIBS += -lgcc
 EXTRA_LIBPATHS += -L "${dir ${shell $(CC) $(ARCHCPUFLAGS) --print-libgcc-file-name}}"

+$(warning libgcc= ${shell $(CC) $(ARCHCPUFLAGS) --print-libgcc-file-name})
+$(warning EXTRA_LIBPATHS=$(EXTRA_LIBPATHS))
+
 ifneq ($(CONFIG_LIBM),y)
   EXTRA_LIBS += -lm
   EXTRA_LIBPATHS += -L "${dir ${shell $(CC) $(ARCHCPUFLAGS) --print-file-name=libm.a}}"

Now we see:

make[1]: Entering directory '/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/arch/arm/src'
/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/arch/arm/src/armv7-m/Toolchain.defs:158: libgcc= c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v7e-m/nofp/libgcc.a
/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/arch/arm/src/armv7-m/Toolchain.defs:159: EXTRA_LIBPATHS=-L "c:/ ./ (x86)/ ./ ./ embedded/ 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v7e-m/nofp/"
make[2]: Entering directory '/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/arch/arm/src/board'
/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/arch/arm/src/armv7-m/Toolchain.defs:158: libgcc= c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v7e-m/nofp/libgcc.a
/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/arch/arm/src/armv7-m/Toolchain.defs:159: EXTRA_LIBPATHS=-L "c:/ ./ (x86)/ ./ ./ embedded/ 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v7e-m/nofp/"
/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/arch/arm/src/armv7-m/Toolchain.defs:158: libgcc= c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v7e-m/nofp/libgcc.a
/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/arch/arm/src/armv7-m/Toolchain.defs:159: EXTRA_LIBPATHS=-L "c:/ ./ (x86)/ ./ ./ embedded/ 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v7e-m/nofp/" -L "c:/ ./ (x86)/ ./ ./ embedded/ 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/nofp/" -L "c:/ ./ (x86)/ ./ ./ embedded/ 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v7e-m/nofp/"
make[2]: 'libboard.a' is up to date.
make[2]: Leaving directory '/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/arch/arm/src/board'
LD: nuttx
C:\Program Files (x86)\GNU Tools ARM Embedded\9 2019-q4-major\bin\arm-none-eabi-ld.exe: cannot find -lgcc
C:\Program Files (x86)\GNU Tools ARM Embedded\9 2019-q4-major\bin\arm-none-eabi-ld.exe: cannot find -lm
make[1]: *** [Makefile:172: nuttx.exe] Error 1

Proving that PR #1450 is the cause of the Cygwin build failure.

[btashton]

This has been broken since July 15. This is why is it essential to get at least one Cygwin build using a Windows native toolchain into the PR checks.

There is a PR that I put up months aggo and then closed a couple days ago because I did not have the time to finish that adds Cygwin to the CI. I did not quite understand how to get the right toolchain involved, but we could at least get the sim building which hits a lot of the build infrastructure code.

[patacongo]

I believe the the root cause of the problem is this:

1. When a Windows native tool is used (ie., CONFIG_CYGWIN_TOOL=y), then the compiler will return a Windows style path and not a POSIX compatible path
2. the make 'dir' command expects a POSIX style path.

So the solution might be to use cygpath to convert the windows path to a Windows path like:

EXTRA_LIBS += -lgcc
LIBGCC_PATH = ${shell $(CC) $(ARCHCPUFLAGS) --print-file-name=libgcc.a}

ifeq ($(CONFIG_CYWGIN_WINTOOL),y)
  EXTRA_LIBPATHS += -L "${dir $(shell cygpath -u $(LIBGCC_PATH)}"
else
  EXTRA_LIBPATHS += -L "${dir $(LIBGCC_PATH)}"
endif

[xiaoxiang781216]

But EXTRA_LIBPATHS is finally consumed by arm-none-eabi-ld which require Windows style path, not POSIX style path?

[patacongo]

But EXTRA_LIBPATHS is finally consumed by arm-none-eabi-ld which require Windows style path, not POSIX style path?

The Bash dirname seems to work okay:

$ 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
$ dirname "c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/libgcc.a"
c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1