Absolute dependency paths by using -MMD in compiler flags

Asked by Johann

I'm creating dependency files (*.d with -MMD flag) during compilation time.
Till version 4.8 2014q1 it was ok and there were no problems. Here is a small example:

"D:/devtools/GNU_ARM/4.8 2014q1/"bin/arm-none-eabi-gcc -mcpu=cortex-m0 -mfloat-abi=soft -mthumb -DMC_TARGET=MC_MCU_NUC140VE3CN -D__CM3_REV=0x0301 -Os -ffunction-sections -Wall -Wextra -Wmissing-include-dirs -Winit-self -Wswitch-enum -Wfloat-equal -Wundef -Wshadow -Wbad-function-cast -Wcast-qual -Wpacked -Wcast-align -Wswitch-default -Wlogical-op -std=c99 -I ../../../../source/examples/boards/NuTiny-SDK-NUC140 -I ../../../../../Libraries/CMSIS/CMSIS/Include -I ../../../../source/device/nuvoton/nuc140 -c main.c -o ../../../../objs/GCC-ARM/main.o -MMD

The content of the main.d file is:
../../../../objs/GCC-ARM/main.o: main.c \
 ../../../../source/device/nuvoton/nuc140/NUC1xx.h \
 ../../../../../Libraries/CMSIS/CMSIS/Include/core_cm0.h \
 ../../../../../Libraries/CMSIS/CMSIS/Include/core_cmInstr.h \
 ../../../../../Libraries/CMSIS/CMSIS/Include/core_cmFunc.h \
 ../../../../source/device/nuvoton/nuc140/system_NUC1xx.h

Using versions 4.8 2014q2 and 4.8 2014q3 the content of main.d is different. Here is an example:
"D:/devtools/GNU_ARM/4.8 2014q3/"bin/arm-none-eabi-gcc -mcpu=cortex-m0 -mfloat-abi=soft -mthumb -DMC_TARGET=MC_MCU_NUC140VE3CN -D__CM3_REV=0x0301 -Os -ffunction-sections -Wall -Wextra -Wmissing-include-dirs -Winit-self -Wswitch-enum -Wfloat-equal -Wundef -Wshadow -Wbad-function-cast -Wcast-qual -Wpacked -Wcast-align -Wswitch-default -Wlogical-op -std=c99 -I ../../../../source/examples/boards/NuTiny-SDK-NUC140 -I ../../../../../Libraries/CMSIS/CMSIS/Include -I ../../../../source/device/nuvoton/nuc140 -c main.c -o ../../../../objs/GCC-ARM/main.o -MMD

The content of the main.d file is:
../../../../objs/GCC-ARM/main.o: main.c \
 ../../../../source/device/nuvoton/nuc140/NUC1xx.h \
 l:\projekte\libraries\cmsis\cmsis\include\core_cm0.h \
 l:\projekte\libraries\cmsis\cmsis\include\core_cminstr.h \
 l:\projekte\libraries\cmsis\cmsis\include\core_cmfunc.h \
 ../../../../source/device/nuvoton/nuc140/system_NUC1xx.h

This absolute paths cause following error at next call of Makefile:
../../../../objs/GCC-ARM/main.d:1: *** multiple target patterns. Stop.

Is it a bub? If yes where should it be posted?

If it's not a bug, what could be the solution?

Thanks!

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Johann
Solved:
Last query:
Last reply:
Revision history for this message
Terry Guo (terry.guo) said :
#1

Thanks for reporting.

How is your Makefile used on Windows, under some IDE or under CYGWIN or via windows make.exe?

Revision history for this message
Johann (johann-tiderko) said :
#2

I'm using make from cygwin to run Makefile.

Revision history for this message
Terry Guo (terry.guo) said :
#3

I am trying to reproduce this issue, but all I got are relative paths to header files. Would you please share a reduced project here for us to reproduce? Thanks.

Revision history for this message
Johann (johann-tiderko) said :
#4

OK I was able to reproduce this issue at another machine (Win7 Home Premium, x64):
  >make --version
  GNU Make 4.0
  Built for i686-pc-cygwin

I become this issue when the name of "project root folder" is smaller than 10 chars.

Dependency with absolute paths:
d:\exmpl_prj\example\source\examples\boards\NuTiny-SDK-NUC140\

Dependency with relative paths:
d:\exmpl_project\example\source\examples\boards\NuTiny-SDK-NUC140\

You can download the complete example project from here:
https://drive.google.com/folderview?id=0B_0ts43RinBVZFFWRkp1SHdwTmM&usp=sharing

Revision history for this message
Terry Guo (terry.guo) said :
#5

Thanks for the project. I can reproduce it now.

Revision history for this message
Terry Guo (terry.guo) said :
#6

Due to the DOS path length limitation, the recent tool chain includes a new feature which will attempt to canonical the relative path and its corresponding absolute path. The shorter one among them will be selected and used in .d file. That's why we see windows absolute paths in .d file. So far so good.

Unfortunately the make in cygwin doesn't support windows path any more since version 3.81. Looks like this is a principle issue, please refer to discussion https://cygwin.com/ml/cygwin/2006-07/msg00671.html.

Good news is that we have mingw-make which supports windows path. Please find the solution from http://my-tech-talk.blogspot.jp/2011/08/how-to-fix-cygwin-make.html.

Revision history for this message
Johann (johann-tiderko) said :
#7

Thanks for the explanation and workaround of this issue.

What is the reason to take a shorter absolute path?
Is it not better to work always with relative paths?
In addition the relative paths keep case-sensitive names and absolute not!

Revision history for this message
Terry Guo (terry.guo) said :
#8

Like I said, the DOS system has path length limitation which caused some other issues before. So the tool chain includes a new feature to ALWAYS select shorter path between relative and absolute paths.

The windows/dos system are case-insensitive system, so the tool chain always chooses lower cases.