Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Honored Contributor I
1,071 Views

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

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
0 Kudos
8 Replies
Highlighted
Honored Contributor I
67 Views

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?
0 Kudos
Highlighted
Honored Contributor I
67 Views

 

--- 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.
0 Kudos
Highlighted
Honored Contributor I
67 Views

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?
0 Kudos
Highlighted
Honored Contributor I
67 Views

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.
0 Kudos
Highlighted
Honored Contributor I
67 Views

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...
0 Kudos
Highlighted
Honored Contributor I
67 Views

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

0 Kudos
Highlighted
Honored Contributor I
67 Views

Thanks that did the trick!

0 Kudos
Highlighted
Honored Contributor I
67 Views

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.
0 Kudos