- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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=7213Link Copied
8 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, you probably need a colon-equal instead of an equal in my syntax. PATH:=.......
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks that did the trick!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page