Cygwin Build Broken #1672

patacongo · 2020-08-30T18:10:51Z

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!

The text was updated successfully, but these errors were encountered:

patacongo · 2020-08-30T18:17:19Z

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 · 2020-08-30T18:18:24Z

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

protobits · 2020-08-30T18:18:48Z

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

patacongo · 2020-08-30T18:22:57Z

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

$ 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 · 2020-08-30T18:42:12Z

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 · 2020-08-30T19:23:19Z

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

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
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 · 2020-08-31T07:10:14Z

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

patacongo · 2020-08-31T17:03:49Z

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

PR apache#1450 broke the Cygwin build. Refer to Issue apache#1672. The use of of logic like: EXTRA_LIBPATHS += -L "${dir ${shell $(CC) $(ARCHCPUFLAGS) --print-file-name=libgcc.a}}" fails when the Toolchain $(CC) is a native Windows toolchain. That is because the returned path is a Windows-style patch which cannot be handled by the make 'dir' command. Commit 4910d43 reorganized a lot of definitions and replaced the correct code with the use of the limit make 'dir' command. The original code used the Bash dirname command which does not suffer from this limitation; it can handle both POSIX and Windows paths. This was verified using the stm32f4discover:nsh toolchain with the Windows native ARM Embedded toolchain. That toolchain returns: 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

patacongo · 2020-08-31T18:48:58Z

PR #1682 appears to correct this problem. With that change applied:

make[2]: Leaving directory '/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/arch/arm/src/board'
echo "LD: nuttx"
LD: nuttx
arm-none-eabi-ld --entry=__start -nostartfiles -nodefaultlibs -T "D:\Spuda\Documents\projects\nuttx\master\nuttx_fork\boards\arm\stm32\stm32f4discovery\scripts\ld.script"  -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:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v7e-m/nofp" -L "c:/program files (x86)/gnu tools arm embedded/9 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
arm-none-eabi-nm "D:\Spuda\Documents\projects\nuttx\master\nuttx_fork\nuttx.exe" | \
grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | \
sort > /cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/System.map
make[1]: Leaving directory '/cygdrive/d/Spuda/Documents/projects/nuttx/master/nuttx_fork/arch/arm/src'
if [ -w /tftpboot ] ; then \
        cp -f nuttx.exe /tftpboot/nuttx.exe.arm; \
fi
CP: nuttx.hex
arm-none-eabi-objcopy  -O ihex nuttx.exe nuttx.hex
CP: nuttx.bin
arm-none-eabi-objcopy  -O binary nuttx.exe nuttx.bin

PR #1450 broke the Cygwin build. Refer to Issue #1672. The use of of logic like: EXTRA_LIBPATHS += -L "${dir ${shell $(CC) $(ARCHCPUFLAGS) --print-file-name=libgcc.a}}" fails when the Toolchain $(CC) is a native Windows toolchain. That is because the returned path is a Windows-style patch which cannot be handled by the make 'dir' command. Commit 4910d43 reorganized a lot of definitions and replaced the correct code with the use of the limit make 'dir' command. The original code used the Bash dirname command which does not suffer from this limitation; it can handle both POSIX and Windows paths. This was verified using the stm32f4discover:nsh toolchain with the Windows native ARM Embedded toolchain. That toolchain returns: 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

patacongo added blocker Release Blocker bug Something isn't working labels Aug 30, 2020

protobits added this to the v10.0 milestone Aug 30, 2020

btashton mentioned this issue Aug 30, 2020

WIP: Add Cygwin to CI apache/nuttx-testing#39

Draft

patacongo mentioned this issue Aug 31, 2020

Fix Cygwin build with Windows native toolchain #1682

Merged

patacongo linked a pull request Aug 31, 2020 that will close this issue

Fix Cygwin build with Windows native toolchain #1682

Merged

xiaoxiang781216 closed this as completed in #1682 Sep 1, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cygwin Build Broken #1672

Cygwin Build Broken #1672

patacongo commented Aug 30, 2020

patacongo commented Aug 30, 2020

protobits commented Aug 30, 2020

protobits commented Aug 30, 2020

patacongo commented Aug 30, 2020

patacongo commented Aug 30, 2020

btashton commented Aug 30, 2020

patacongo commented Aug 30, 2020 •

edited

Loading

xiaoxiang781216 commented Aug 31, 2020

patacongo commented Aug 31, 2020

patacongo commented Aug 31, 2020

Cygwin Build Broken #1672

Cygwin Build Broken #1672

Comments

patacongo commented Aug 30, 2020

patacongo commented Aug 30, 2020

protobits commented Aug 30, 2020

protobits commented Aug 30, 2020

patacongo commented Aug 30, 2020

patacongo commented Aug 30, 2020

btashton commented Aug 30, 2020

patacongo commented Aug 30, 2020 • edited Loading

xiaoxiang781216 commented Aug 31, 2020

patacongo commented Aug 31, 2020

patacongo commented Aug 31, 2020

patacongo commented Aug 30, 2020 •

edited

Loading