nios2-elf-objcopy: command not found in Cygwin Windows 7, Nios II 12.1

[Altera_Forum]

Hi, 

We have a bunch of existing scripts used to generate srecs, .sh files. The scripts have been running for many years so I feel that the work.  I am in the process of converting our build environement to Nios II 12.1.  We run a make srecs script from the Nios II 12.1 Command Shell When I run one of the scripts I get the nios2-elf-objcopy: command not found message. When I try to do a "which nios2-" and then tab to auto complete no command show up as options However, when I type "which nios2-elf-objcopy", the path is shown. Then I "printenv PATH" and can see the path in my listed first thing in the path. I do a nios2-elf-objcopy --help from the command prompt and help comes up?  I have noticed a lot of mix and match between C: and /cygdrive/c and I have confirm C: is mapped using df -k. I have even seen modifications to my path to make all the /cygdrive/c into C:'s, not sure which part of the tools do this or even if it is important here.  See screen shot... Any ideas on what else to look for?  Thanks in advance, jennifer  https://www.alteraforum.com/forum/attachment.php?attachmentid=7213

[Altera_Forum]

Little more info: 

My make file edits the path  PATH="${PATH}:../../../../libs/scripts" ;  I commented this out and added the path in my .bachrc file instead and now it works. However, I would like to have the PATH modified in the file as it has advantages that way. Why would editing the path from the make file have a different effect?

[Altera_Forum]

--- Quote Start ---   When I run one of the scripts I get the nios2-elf-objcopy: command not found message.   --- Quote End ---    It sounds like the environment within the shell script context is different from the environment on the command prompt. You could start by comparing the output from "printenv PATH" on or around line 175 of your script to what you get on the interactive prompt. It might be something simple like your scripts have variables set corresponding to prior versions of the tools.

[Altera_Forum]

I can see that my PATH names have C: in them when running the make file and /cygdrive/c when running from the command prompt.  

Our old make tools ran off of make version 3.x.x and the 12.1 run off of version 4.x.x  What type of variables you are referring to might cause a change in how setting a PATH is handled?

[Altera_Forum]

I'm not sure how your Makefile is performing the PATH modification, but, 

 it works fine for me if and only if you get rid of the quotes and use parens. Something like:   PATH=$(PATH);../xbin all : xbin_foo   (and if xbin_foo is a cygwin shell script that just does printenv PATH from within it will correctly show the Cygwin style paths, modified with ../xbin at the tail end )   If I try using curly brace and quotes per your example, I get errors. I have no idea if this is only a problem for you now due to the change in Make version.  Also, "echo ${PATH}" from the Makefile will display DOS style; but scripts invoked from the Makefile will correctly have Cygwin-UNIX style paths.

[Altera_Forum]

When I use the syntax you provide I get a Recursive variable PATH error. 

If I put it in all:  ( PATH=$(PATH);../xbin   xbin_foo )  I get a syntax error  Thanks for the help, I have to admit Makefile syntax often confuses me...

[Altera_Forum]

Sorry, you probably need a colon-equal instead of an equal in my syntax. PATH:=.......

[Altera_Forum]

Thanks that did the trick!

[Altera_Forum]

The " would cause a problem because make doesn't treat them as special characters - so the PATH env variable will have the " embedded in it. 

Some places might expand the output twice (eg echo $(PATH) in a makefile rule, but not echo $$PATH) so the shell removes the extra quotes.