I try to run a makefile and I need to set the path in which the ifort compiler is located. I try the following line:
export PATH=$PATH:/opt/intel/Compiler/11.0/081/bin/intel:/usr/bin
in a past makefile something like that worked well. But now, and I almost sure I miss the correct spelling of the export line, doesn't want to work properly.
In fact it gave to me the following error message:
/opt/.../intel64/ifort: uname: command not found
It seams that it do not recover this address.
Should I probability change /opt/../bin/... whit /include/ or others path in the Compiler directory?
Is maybe the last :/usr/bin part of the address incorrect?
EDIT 1
I try to follow the suggestions in the comments using, at the second line of the Makefile, the follow line:
export PATH:=$(PATH):/opt/intel/Compiler/11.0/081/bin/intel64:/usr/bin
but I receive the following error message:
MyGa.f90:(.text+0x28): undefined reference to "__intel_new_feature_proc_init"
Is it possible I have to change the line of the export command from the second to the first one or the :/usr/bin directory path?
Many thanks for your help.
is uname present in the bin?
try this:
ls -l /bin/uname
to check if it's present
-rwxr-xr-x 1 root root 35032 Jan 18 2018 /bin/uname (if present)
if it is present then check your PATH variable
echo $PATH
Related
I've just set up a cross-helloworld automake project (for stm32f4-discovery). There I have a custom discovery.ld scrpt. I put a line in my Makefile.amAM_LDFLAGS = -T discovery.ld. The problem starts when I run confgure from a different folder (e.g. /path/to/source/build) to the one in which the script is situated (/path/to/source). Effectively, being in /path/to/source/build directory, make runs gcc -T discovery.ld ... and fails to find the script because it's in /path/to/source directory and it's not included in the search path list.
-L/path/to/source or -L.. would solve the problem but I don't want to hardcode things.
Maybe there a autoconf/automake variable exists which points to the folder where configure script (and also my discovery.ld) are situated so that I could use it in my Makefile.am?
I'd be glad to any advice.
Many thanks to William Pursell:
AM_LDFLAGS = -T $(top_srcdir)/path/to/discovery.ld
I have a problem with invoking gcov, it keeps returning - No such file or directory.
When I call
localhost:R-3.0.1 romantsegelskyi$ gcov src/main/eval.c
eval.c: No such file or directory
However file itself and information needed for gcov exists.
localhost:R-3.0.1 romantsegelskyi$ ls src/main/eval*
src/main/eval.c src/main/eval.d src/main/eval.gcda src/main/eval.gcno src/main/eval.o
I have tried specifying --object-directory but still no luck
localhost:R-3.0.1 romantsegelskyi$ gcov src/main/eval.c --object-directory=./src/main
eval.c: No such file or directory
Strangest thing is that it is only the case on OSX, on Linux everything works fine as intended. Any ideas?
Same behavior !! And more strange : I get the result (the .gcov file), following this mesg !! Perhaps, you have the result too ?
There two aspects in the problem :
gcov manual said that gcov should execute by default in the directory where the object file and the gcov data files are. The first and simplest working solution is : go in the appropriate directory and execute gcov cd src/main; gcov eval.c
why the --object-directory=... arg seems not working ? Because the expected value is a directory name and in the example given, it is a file name. So you should write --object-directory=src/main (this work too)
or --object-file=src/main/eval.c (according to the doc. I haven't tried this !)
I have the following directory structure:
base/
dir/
subdir/
link -> ../dir
Now if I cd to dir/link and type:
cd ../subd[tab]
I get:
cd ../subdir[space]
I would understand if autocomplete fails (because it would canonize the path and look into base/ and not dir/).
I would also understand if it autocompletes to cd ../subdir/ with the ending / (because it would interpret .. as go up one level and search into dir/).
But I do not understand the actual behaviour that is somewhere between the two. Ideally I would like bash to behave like 2. (autocomplete to cd ../subdir/). I am using fedora 14, bash version 4.1.7(1). Any idea how to accomplish this ?
UPDATE: The program with which you can customize auto-completion is called complete.
You can find some good basic examples here: More on Using the Bash Complete Command
Using function and script names as per the above link, here is a script which appends the / to a symbolic link to a directory... It is just a rough sample, but it shows it can be done (I haven't tried it with the cd builtin...
Associate the function _mycomplete_ with executable myfoo
complete -F _mycomplete_ myfoo
The function to go in ~/.bashrc
function _mycomplete_()
{
local cmd="${1##*/}"
local word=${COMP_WORDS[COMP_CWORD]}
local line=${COMP_LINE}
local xpat='!*.foo'
COMPREPLY=($(compgen -f -X "$xpat" -- "${word}"))
if ((${#COMPREPLY[#]}==1)) ;then
[[ -h $COMPREPLY ]] && COMPREPLY="$COMPREPLY/"
fi
}
Original answer:
At the command-line, the main indicator of a auto-expansion to a symbolic link is shown on the last line of the following table, ie. a name expands but without the final /.
on pressing TAB on pressing TAB (again)
what happens? meaning what happens?
=================== ======================= ====================================
Nothing is appended 1=> Multiple sub-dirs exist => A list of possibilities is presented
2=> No sub-directory exists => Nothing is appended (again)
Expands to end in / => A uniquely matching dir => ...as per first column (repeat)
Expands text only => Current name is a link => Expands to end in /
In your example, if you have already primed the command-line to the full name, ie. cd link then the indicator is not obvious. Also you won't know it is a symbolic link via the list of possibilities.
To be able to cd to the link's target, you can use cd -P link, or set -P; cd link
After digging the source code a bit, it looks like this is a bit complicated. The actual problem is a mix between bash allowing symlinks inside the working directory (see pwd -L and pwd -P) and readline not able to determine the type of a match if it is not in a physical directory
In readline/complete.c:1694
s = (nontrivial_match && rl_completion_mark_symlink_dirs == 0)
? LSTAT (filename, &finfo)
: stat (filename, &finfo);
stat() fails since ../ is understood as relative to the physical path and not the logical path. readline fails to determine this is a directory and therefore does not append the final '/'.
A very similar problem is described here
So I guess I can live with the existing behaviour for now...
I was having the exact same problem in Ubuntu. Autocompletion was working like in your example #2, but started working as you describe at some point. I purged and reinstalled the package bash-completion, and now everything seems back to normal. Do not uninstall bash! Only bash-autocompletion.
Edit
look at this:
https://bbs.archlinux.org/viewtopic.php?id=113158
Hi I am searching for a good solution since a while and I found nothing to help me on google.
I got an error on my website with the function mkdir, but only when I set the debug at 2.
Here is the error
Warning (2): mkdir() [function.mkdir]: Invalid argument
[CORE\cake\libs\folder.php, line 498]
Im on windows server 2003 and every permission are given to all my folder.
The path that is given to the function is
C:\Inetpub\vhosts[DOMAIN NAME]\subdomains[SUBDOMAIN
NAME]\httpdocs\app\webroot\C:
I notice the last C: at the end of the path but don't know where it come from nor does I know what the function is trying to create.
mkdir() should ideally take the path to directory and should not include the file name. The invalid argument warning seems to suggest the same. Try passing the argument without filename.
/Thanks.
When I'm trying to run autogen from MSys 1.11 on a source, it always giving an error called,
configure.ac:9: option 'tar-ustar' not recognized
Can anyone please help me to get-rid of this error ?
Note:
andtar-v7, tar-ustar, tar-pax. all these 3 didn't work. Thank you...
Just remove the tar-ustar option from your configure.ac file (look for an AM_INIT_AUTOMAKE line) or install a newer version of Automake (1.9+). It should fall back to v7-style tar (in spite of not recognizing tar-v7).
tar is the command - the '-' and the letters after it is a parameter. You want:
tar -ustar
notice the space. Having said that, I don't believe that -ustar is a valid combination of tar options, but you should get a different error message for that.