make not reading Cygwin-style paths

[mmomtchev]

This make seems to lack support for Cygwin-style paths (/c/users/...) that are sometimes produces by configure scripts.

If the Makefile references such a path, this make is unable find it.

[ilg-ul]

This is weird, since Make is the same as in the previous release, 4.4.1, only BusyBox was updated.

[mmomtchev]

I haven't tested the previous release and I tried with another make - from https://github.com/maweil/MakeForWindows - which also lacked support - so I think that this must be common - I don't know where it is coming from, but the base distribution from GNU does not have it.

The MSYS2 or MinGW make does have it tho.

[ilg-ul]

Can you identify a build script for a make that you know to be functional, so we can compare the configure options?

[mmomtchev]

I will try to reproduce it outisde of conan - I have a bash from MSYS2 which produces it with xz_utils.

I think it is a question of which runtime is used?

Here is the beginning of my config.log:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by XZ Utils configure 5.4.5, which was
generated by GNU Autoconf 2.71.  Invocation command line was

  $ /c/users/mmom/appdata/local/hadron/p/b/xz_utac757c4a228bc/b/src/configure --disable-shared --enable-static --prefix=/ --bindir=/bin --sbindir=/bin --libdir=/lib --includedir=/include --oldincludedir=/include --disable-doc

## --------- ##
## Platform. ##
## --------- ##

hostname = mmom-desktop
uname -m = x86_64
uname -r = 3.4.9.x86_64
uname -s = MINGW64_NT-10.0-22631
uname -v = 2023-09-15 12:15 UTC

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = x86_64
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /c/users/mmom/appdata/local/hadron/p/msys27f2f094a41efb/p/bin/
PATH: /c/users/mmom/appdata/local/hadron/p/msys27f2f094a41efb/p/bin/msys64/usr/bin/
PATH: /mingw64/bin/
PATH: /usr/local/bin/
PATH: /usr/bin/
PATH: /bin/

[ilg-ul]

I did a build with the latest make for an Eclipse project, and it passed, with the forward slash separators:

Building file: ../src/timer.cpp
Invoking: GNU Arm Cross C++ Compiler
arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -Og -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -fno-move-loop-invariants -Wall -Wextra -g3 -DDEBUG -DUSE_FULL_ASSERT -DTRACE -DOS_USE_TRACE_SEMIHOSTING_DEBUG -DSTM32F407xx -DUSE_HAL_DRIVER -DHSE_VALUE=8000000 -I"../include" -I"../system/include" -I"../system/include/cmsis" -I"../system/include/stm32f4-hal" -std=gnu++11 -fabi-version=0 -fno-exceptions -fno-rtti -fno-use-cxa-atexit -fno-threadsafe-statics -MMD -MP -MF"src/timer.d" -MT"src/timer.o" -c -o "src/timer.o" "../src/timer.cpp"
Finished building: ../src/timer.cpp

Building file: ../src/write.c
Invoking: GNU Arm Cross C Compiler
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -Og -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -fno-move-loop-invariants -Wall -Wextra -g3 -DDEBUG -DUSE_FULL_ASSERT -DTRACE -DOS_USE_TRACE_SEMIHOSTING_DEBUG -DSTM32F407xx -DUSE_HAL_DRIVER -DHSE_VALUE=8000000 -I"../include" -I"../system/include" -I"../system/include/cmsis" -I"../system/include/stm32f4-hal" -std=gnu11 -MMD -MP -MF"src/write.d" -MT"src/write.o" -c -o "src/write.o" "../src/write.c"
Finished building: ../src/write.c

Building target: f4.elf
Invoking: GNU Arm Cross C++ Linker
arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -Og -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -fno-move-loop-invariants -Wall -Wextra -g3 -T mem.ld -T libs.ld -T sections.ld -nostartfiles -Xlinker --gc-sections -L"../ldscripts" -Wl,-Map,"f4.map" --specs=nano.specs -o "f4.elf" ./system/src/stm32f4-hal/stm32f4xx_hal.o ./system/src/stm32f4-hal/stm32f4xx_hal_cortex.o ./system/src/stm32f4-hal/stm32f4xx_hal_flash.o ./system/src/stm32f4-hal/stm32f4xx_hal_flash_ex.o ./system/src/stm32f4-hal/stm32f4xx_hal_flash_ramfunc.o ./system/src/stm32f4-hal/stm32f4xx_hal_gpio.o ./system/src/stm32f4-hal/stm32f4xx_hal_iwdg.o ./system/src/stm32f4-hal/stm32f4xx_hal_pwr.o ./system/src/stm32f4-hal/stm32f4xx_hal_rcc.o  ./system/src/newlib/assert.o ./system/src/newlib/cxx.o ./system/src/newlib/exit.o ./system/src/newlib/sbrk.o ./system/src/newlib/startup.o ./system/src/newlib/syscalls.o  ./system/src/diag/trace-impl.o ./system/src/diag/trace.o  ./system/src/cortexm/exception-handlers.o ./system/src/cortexm/initialize-hardware.o ./system/src/cortexm/reset-hardware.o  ./system/src/cmsis/system_stm32f4xx.o ./system/src/cmsis/vectors_stm32f407xx.o  ./src/initialize-hardware.o ./src/led.o ./src/main.o ./src/stm32f4xx_hal_msp.o ./src/timer.o ./src/write.o   
c:/users/ilg/appdata/roaming/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/12.3.1-1.2.1/.content/bin/../lib/gcc/arm-none-eabi/12.3.1/../../../../arm-none-eabi/bin/ld.exe: warning: f4.elf has a LOAD segment with RWX permissions
Finished building target: f4.elf

So the forward slash is functional, but with Windows c:/ drive names, not with Cygwin /c/ style.

If there is a configure option to make it support both, I can add it.

[mmomtchev]

Let me check where it comes from, only the make from MSYS2 and Cygwin support this, maybe they have their own runtime which does it. Maybe it is not supposed to be mixed with other MinGW tools.

[mmomtchev]

This is not your problem.

from https://www.msys2.org/docs/filesystem-paths/:

The only solution here is to avoid mixing Unix/Cygwin and native tools outside of makepkg (preferred) or convert them when they get passed between the different programs. For the latter MSYS2 provides an automatic conversion that just works automatically in many cases.

[ilg-ul]

Ok, thank you for investigating.