Windows dependency file contains invalid absolute paths

[Matthew Page]

Toolchain: 10.0 Q4 2020 (verified with binary package only)
Host machine: Windows 10 build 1803 (Command Prompt, nmake 9.0)

The Windows toolchain releases enabled automatic conversion from relative to absolute paths (ENABLE_CANONICAL_SYSTEM_HEADERS) with version 4.8 Q2 2014. In my project I enable -MMD to get dependency (.d) files generated as part of the compilation.

The path conversion works fine in these .d files using any version from 4.8 Q2 2014 to 9.0 Q2 2020 update. If I update to 10.0 Q4 2020, any converted paths in my .d files start with the incorrect prefix "c\:" instead of "c:", which then breaks subsequent builds.

Example minimal project attached:
- Extract zip to c:\test
- Zip contains test.c, which does nothing useful but include test.h using a long relative path (via the dummy subdirectory 0123456789ABCDEF)
- Set environment variable _GCCARM_CC_BIN to the bin folder of your GCC ARM 10.0 installation (or just modify the CC path in MAKEFILE)
- Compile and check output test.d dependency file contents:
    test.exe: test.c c\:\test\test.h

Downgrading the toolchain below 10.0 produces the correct output in test.d:
    test.exe: test.c c:\test\test.h

[Przemyslaw Wirkus (wirkus)]

Hi,

Is this issue (https://bugs.linaro.org/show_bug.cgi?id=5750) similar to yours Matthew?

/Przemek

[Przemyslaw Wirkus (wirkus)]

I will just paste my answer from Linaro's BUgzilla here:

Hi,

This "escaping" is not working for old Make (like 3.81). With newer make from Mingw I can successfully use escaped string supplied by -M option:

In c:\tmp\, on Windows 10 in CMD window.

$ set PATH /path/to/new/mingw/make;%PATH%

$ cat Makefile
CC=C:\Users\przwir01\Downloads\gcc-arm-10.2-2020.11-mingw-w64-i686-aarch64-none-elf.tar\gcc-arm-10.2-2020.11-mingw-w64-i686-aarch64-none-elf\bin\aarch64-none-elf-g++.exe
CFLAGS=-I.

%.o: %.c
        $(CC) -c -o $@ $< $(CFLAGS)

test.o: c\:\tmp\test.c

$ cat test.c
int main(int, char **c) { return 0; }

$ make --version
GNU Make 4.2.1
Built for i686-w64-mingw32
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

$ make
C:\Users\przwir01\Downloads\gcc-arm-10.2-2020.11-mingw-w64-i686-aarch64-none-elf.tar\gcc-arm-10.2-2020.11-mingw-w64-i686-aarch64-none-elf\bin\aarch64-none-elf-g++.exe -c -o test.o test.c -I.

c:\tmp>dir
 Volume in drive C is OSDisk
 Volume Serial Number is 287A-D1CC

 Directory of c:\tmp

01/03/2021 12:25 <DIR> .
01/03/2021 12:25 <DIR> ..
01/03/2021 12:17 249 Makefile
01/03/2021 11:50 39 test.c
01/03/2021 12:25 1,232 test.o
               3 File(s) 1,520 bytes
               2 Dir(s) 322,285,154,304 bytes free

[Matthew Page (matthew-page)]

Przemek,

The issue you linked does appear similar as far as the outcome. Although in our build environments we are typically using nmake (v9.0) or mingw make (v3.82), which unfortunately both break when doing repeated builds with these bad paths.

There is a workaround of course to run a script to fix every .d file in the tree, but it would be preferable to fix whatever broke this if possible (not sure if it was an intentional change or just a defect that crept in).

[Przemyslaw Wirkus (wirkus)]

Hi Matthew,

GCC https://gcc.gnu.org/install/prerequisites.html does say:

"""
GNU make version 3.80 (or later)

    You must have GNU make installed to build GCC.
"""

(Docs might be out of date).

I will try to find some time and finally check GCC code base for this change (escape of ':').

PS: Dependencies tools/packages necessary for building GCC change over time. Slowly but steadily. It might be that in your case you might have to update your `make` family (or hack with script).

/Przemek

[Przemyslaw Wirkus (wirkus)]

Just a side comment: I've checked and we've moved to GNU make 4.1 some time ago in our toolchain infrastructure.

[Przemyslaw Wirkus (wirkus)]

Ah, just a clarification on "GCC prerequisites" comment I've made earlier: Of course prerequisites to build GCC and your project are different. But still, it's just a bit strange that GCC emits .d files which are not compatible with its own GNU make 3.80 prerequisite. One could build GCC with extra .d files generated AFAIK.

[Matthew Page (matthew-page)]

Thanks for the info. Look forward to seeing what you can find out in the code base for where/why this broke. As you mentioned, we are indeed building only our own projects (and not GCC itself).