This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/TDA3: TI ARM v17.6.0.STS automatic library build fails under Windows 10, apparently due to unquoted echo command in the RTS library Makefile

Part Number: TDA3


Tool/software: TI C/C++ Compiler

Having installed TI ARM v17.6.0.STS into CCS 7.2.0.00013 running under Windows 10 pro 64-bit the automatic library build was failing. E.g.:

**** Build of configuration Debug for project TDA3x_Cortex_M_sadd16 ****

"C:\\ti\\ccs720\\ccsv7\\utils\\bin\\gmake" -k -j 4 all -O 
'Building target: TDA3x_Cortex_M_sadd16.out'
'Invoking: ARM Linker'
"C:/ti/ccs720/ccsv7/tools/compiler/ti-cgt-arm_17.6.0.STS/bin/armcl" -mv7M4 -g --diag_warning=225 --diag_wrap=off --display_error_number -k -z -m"TDA3x_Cortex_M_sadd16.map" -i"C:/ti/ccs720/ccsv7/tools/compiler/ti-cgt-arm_17.6.0.STS/lib" -i"C:/ti/ccs720/ccsv7/tools/compiler/ti-cgt-arm_17.6.0.STS/include" --reread_libs --diag_wrap=off --display_error_number --warn_sections --xml_link_info="TDA3x_Cortex_M_sadd16_linkInfo.xml" --rom_model --be32 -o "TDA3x_Cortex_M_sadd16.out" "./main.obj"  -llibc.a 
<Linking>
warning #10366-D: automatic library build: using library "C:\ti\ccs720\ccsv7\tools\compiler\ti-cgt-arm_17.6.0.STS\lib\rtsv7M4_T_be_v4SPD16_eabi.lib" for the first time, so it must be built.  This may take a few minutes.
process_begin: CreateProcess(NULL, echo Creating library c:/users/mr_hal~1/appdata/local/temp/ti9b5d~1/rtsv7m4_t_be_v4spd16_eabi.lib, ...) failed.
Makefile:1948: recipe for target 'library' failed
make (e=2): The system cannot find the file specified.

>> Compilation failure
makefile:140: recipe for target 'TDA3x_Cortex_M_sadd16.out' failed

I don't have make, gmake or sh from any other utility in the path. The automatic library build from TI ARM v17.3.0.STS was working.

The error message from the TI ARM v.17.6.0.STS automatic library build says gmake failed to execute the process with the command line "echo Creating library c:/users/mr_hal~1/appdata/local/temp/ti9b5d~1/rtsv7m4_t_be_v4spd16_eabi.lib".

Comparing the TI ARM v17.3.0.STS and v17.6.0.STS installations shows that in the lib\src\Makefile v17.6.0.STS has added an echo as part of the library target:

library: $(ALL_OBJS)
	@echo Creating library $(LIB)
	@$(CD) $(OBJ); $(AR) -qa $(LIB) $(notdir $(ALL_OBJS))

I think the unquoted string in causing gmake to abort the build with an error. As an experiment modified the v17.6.0.STS lib\src\Makefile to quote the echo string and the automatic library build was then successful:

library: $(ALL_OBJS)
	@echo "Creating library $(LIB)"
	@$(CD) $(OBJ); $(AR) -qa $(LIB) $(notdir $(ALL_OBJS))

Not sure if this is a bug in the v17.6.0.STS lib\src\Makefile or something about my PC setup, but at least allowed the automatic library build to complete successfully.

  • Thank you for letting us know about this problem.  I can reproduce it.  I filed CODEGEN-2371 in the SDOWP system to have this addressed.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • Hi Chester,

    I was initially not able to reproduce the behavior you reported with an installation of the ARM 17.6.0.STS Code Generation Tools. I was able to compile and link a simple -mv7m4 application that needed a "missing" RTS library to be built at link-time via the mklib utility. I ran this experiment from a simple command prompt window. However, I was able to reproduce the behavior you reported when compiling and linking a similar application from within the Code Composer Studio (CCS) GUI. The CCS installation comes with its own version of gmake which appears to behave similarly to the version of gmake that you have in your system.

    I can verify that when I applied your suggested workaround, surrounding the "Creating library $(LIB)" with double-quotes in the lib/src/Makefile, then the compile and link experiment using CCS began to work as expected.

    Your workaround will be applied to the Makefile that will be provided with the next STS release (17.9.0.STS).

    Thank you for reporting the issue and taking the time to find a viable workaround. As George mentions below, you can track the defect report CODEGEN-2371 via the SDOWP link.

    Thanks and Regards,
    Todd Snider
  • Todd Snider said:
    However, I was able to reproduce the behavior you reported when compiling and linking a similar application from within the Code Composer Studio (CCS) GUI. The CCS installation comes with its own version of gmake which appears to behave similarly to the version of gmake that you have in your system.

    Looking back at the output from my failure case, the version of gmake which comes with the CCS 7.2 installation was in use.

  • Thanks for reporting this and providing a solution. I was having the same issue and it's solved by following your change in Makefile.