I installed the Intel ifort compiler on my computer but before I can executed the command ifort I need to load the file:
. /opt/intel/composerxe/bin/compilervars.sh intel64
I don't want to load this in every session, therefor I don't want to put
it in my ~/.bashrc.
When I put this line in a Shell Script, like this:
#!/bin/sh
echo "Load environment variables for Intel ifort + Intel MPI"
. /opt/intel/composerxe/bin/compilervars.sh intel64
I get this error:
ERROR: Unknown switch ''. Accepted values: ia32, intel64
Is there another way to source the compilervars.sh with the intel64 flag?
Related
I have a C++ project setup with CMake, running on Mac. Recently I am looking into adding Fortify to do auto code analyzation. I am using Fortify version 22.1.
After set up the CMake and shell scripts, I found that if I compile with more than one CPU (using -j), the compiler (c++ or g++) will have issues generating the libs. Sometimes it will pass and successfully generate the Fortify output, but others it will just error out. Multi CPUs compile fine for this project without running Fortify.
I also see this error when I compile with Fortify (no matter it success or not):
[error]: Translator execution failed. Please consult the Troubleshooting section of the User Manual.
Translator returned status 1:
error: unable to handle compilation, expected exactly one compiler job in ''
This error always happens after a "Linking CXX xxxxx xxxx". I can't find any documentation about them.
Does anyone know how to solve this? Thank you.
Update more details about my setup:
I use shell files to wrap the sourceanalyzer like this:
#!/bin/bash
exec sourceanalyzer -b MyApp /Library/Developer/CommandLineTools/usr/bin/c++ "$#"
And my CMake setup like this:
if (${ENABLE_FORTIFY} EQUAL 1)
set(CMAKE_CC_COMPILER ${AVSxAppDALDefaultImplementation_SOURCE_DIR}/scripts/fortify-build-cc.sh)
set(CMAKE_CXX_COMPILER ${AVSxAppDALDefaultImplementation_SOURCE_DIR}/scripts/fortify-build-cxx.sh)
endif()
My shell script to run CMake and then to the scan:
cmake $PACKAGEPATH \
...
-DENABLE_FORTIFY="${ENABLE_FORTIFY}"
echo "---BUILDING---"
make release
if [[ $ENABLE_FORTIFY == 1 ]]; then
echo "---RUNNING FORTIFY SCAN---"
sourceanalyzer -b ${CURRENT_PROJECT_NAME} -scan -f fortify_scan_result_${CURRENT_PROJECT_NAME}.txt
fi
I just switched to ubuntu and I wanted to setup notepad++ for CPP.
So I used the NppExec plugin to compile within notepad++,
My script was :
npp_save
g++ "$(FULL_CURRENT_PATH)" -o "$(CURRENT_DIRECTORY)\$(NAME_PART)obj"
./"$(NAME_PART)obj"
Here the "obj" I used is to just save the file with an "obj" keyword nothing else.
The last line ./"$(NAME_PART)obj" is to run the program.
But it looks not working in ubuntu, it produces this error:
NPP_SAVE: Z:\home\username\cpp\test.cpp
g++ "Z:\home\username\cpp\test.cpp" -o "Z:\home\username\cpp\testobj"
; about to start a child process: "g++ "Z:\home\username\cpp\test.cpp" -o "Z:\home\username\cpp\testobj"
CreatProcess() failed with error code 2:
File not found.
./"testobj"
; about to start a child process: "./"testobj""
CreatProcess() failed with error code 2:
File not found.
I have investigated some of what I think is the problem, so I think is the usage of / and \ in changing the directory.
I don't know how to fix that, so I can not be sure.
Any ideas? :) I am using vim btw in the same machine and it is working perfectly.
In theory it might be possible (see below), in practice it is rather convoluted and works only for simple compiles (like single file hello world type).
I would suggest you try a linux program, e.g.
an editor like
scite (same editing engine as notepad++) or
kate
or a real IDE like
kdeveloper or
qtcreator.
The problems with Notepad++ inside wine and g++ outside wine (from the linux install ) are this:
notepad++ inside wine under linux is still a windows program
NppExec can only do, what a cmd inside wine can do.
starting g++ directly inside cmd is an error due to g++ being a linux binary and not a windows binary
that is your CreatProcess() failed with error code 2, it means: you are trying to execute a linux program inside wine.
That does not work! (At least not so easy.)
Though you can start linux program inside cmd inside wine using start /unix ...
started this way, g++ wants linux paths and NppExec through its variables will provide only windows paths (whatever wine has set up as drives like Z:\home\username\src\hello.cpp)
though you can convert wine paths to linux paths via the winepath -u command.
g++ started through 'start /unix ... ' inside a cmd inside wine has no proper terminal to report errors to you
though you can start an xterm for g++ and have g++ reports its messages to the xterm
the downside is that g++ will report errors using the linux paths in the xterm, so you cannot double click on an error message an get to the corresponding filename and line.
You get the idea: its complicated not comfortable.
What worked for me for a helloword.cpp was this NppExec script:
NPP_SAVE
npp_run cmd /c start /unix /usr/bin/xterm -e "/usr/bin/winepath -u '$(FULL_CURRENT_PATH)' | xargs g++ -o /tmp/a.out && /tmp/a.out ; echo 'Press return'; read"
The second line
uses an xterm,
let winepath convert the Z:\home\... path to /home/... and
have that send to g++ for compilation using /tmp/a.out as binary
if compile is successfull, /tmp/a.out is executed
the echo and read are for keeping the xterm open so that you can read the output.
If you really want to use Notepad++ inside wine, one option might be using Gnu Make outside of wine and have NppExec run make all or make run similar to the g++ in my script example. That would work for more complicated compiles.
I'm trying to build a cross platform project for Ubuntu. In my makefile I have the line
"PSPSDK=$(shell psp-config --pspsdk-path)"
which gives the error "psp-config: Command not found."
psp-config is in my path and running make from the Ubuntu system on the files that get copied over from Visual Studio works fine. It also works if I manually ssh into the Ubuntu system from windows and run the command from there.
Why can't it find the command when run through Visual Studio?
You should update PATH at the beginning of "~/.bashrc" file (and not at the end) because it starts with somethign like:
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
Also, if you add code before these lines, it will be invoked for every subshell execution, so it is better to add a guard for it as well so it is invoked only once per session:
if [ -z $HOME_OPT_PATH_SET ]; then
export PATH=$PATH:$HOME/opt
export HOME_OPT_PATH_SET=1
fi
# If not running interactively, don't do anything
...
I'm trying to exploit the binaries from Damn vulnerable Router Firmware but I have issues with debuggging with gdb.
to run the program i use this command :
sudo chroot . ./qemu-mipsel-static ./pwnable/Intro/stack_bof_01
and it works but when i try to run gdb with :
sudo chroot . ./qemu-mipsel-static gdb ./pwnable/Intro/stack_bof_01
I have that :
(gdb) r
Starting program: /pwnable/Intro/stack_bof_01
qemu: Unsupported syscall: 4026
Cannot exec /bin/bash: No such file or directory.
qemu: Unsupported syscall: 4026
Could not open /proc/12532/status
I tried to copy the binary in a qemu VM but I don't have the whole system so it don't work.
So , please , what's is the best way to debug a program from a firmware on a different architecture than x86 ?
In qemu user mode, run the program using the command with the option -g:
sudo chroot . ./qemu-mipsel-static -g 1234 ./pwnable/Intro/stack_bof_01
then start the gdb-multiarch (or gdb that corresponds to that architecture), and attach to it like this:
target remote 127.0.0.1:1234
then you can debug it happily.
I just installed CUDA 6.5, VS2013 Community Edition, and pyCUDA. I already had python 2.7.8 installed. I am new to CUDA and VS2013 development but not python. I verified my CUDA install by building some of the CUDA VS2013 sample solutions as both 32- and 64-bit so things work up to that point.
Now I'm trying to verify my pyCUDA install by running this test program.
### from: http://documen.tician.de/pycuda/tutorial.html
import pycuda.gpuarray as gpuarray
import pycuda.driver as cuda
import pycuda.autoinit
import numpy as np
# copy to gpu
a_gpu = gpuarray.to_gpu(np.random.randn(4,4).astype(np.float32))
# double it
a_doubled = (2 * a_gpu).get()
print('a_doubled', a_doubled)
When run, it produces this error:
[snip]
File "B:\Anaconda2\lib\site-packages\pycuda-2014.1-py2.7-win-amd64.egg\pycuda\compiler.py", line 250, in do_compile
return compile_plain(source, options, keep, nvcc, cache_dir)
File "B:\Anaconda2\lib\site-packages\pycuda-2014.1-py2.7-win-amd64.egg\pycuda\compiler.py", line 132, in compile_plain
stderr=stderr.decode("utf-8", "replace"))
CompileError: nvcc compilation of e:\temp\cb4\tmpadhjeh\kernel.cu failed
[command: nvcc -cubin -keep -cudart shared -arch sm_52 -m64 -Ib:\anaconda2\lib\site-packages\pycuda-2014.1-py2.7-win-amd64.egg\pycuda\cuda -keep kernel.cu]
[stdout:kernel.cu]
[stderr:
'B:\VisualStudioCom2013\VC\bin\amd64"\cl.exe #kernel.cpp1.ii.res > "kernel.cpp1.ii' is not recognized as an internal or external command,
operable program or batch file.]
Note the extraneous double quotes in the cl.exe command which are causing the error. Without them I can manually run B:\VisualStudioCom2013\VC\bin\amd64\cl.exe #kernel.cpp1.ii.res > kernel.cpp1.ii. It completes just fine and a valid kernel.cpp1.ii is generated.
Is there some way to control the cl.exe command that nvcc builds? Nothing in the nvcc manual jumped out at me, but with all those options I certainly might've have missed it.
Also posted in this Nvidia developers forum.
This is a bug in nvcc for CUDA 6.5. After following #talonmies suggestion to look through nvcc.profile, I started trying combinations of profile settings and command line options. I narrowed it down to this: when --keep is on the command line AND compiler-bindir is in the nvcc.profile, the malformed cl.exe compile command that includes double quotes is generated. The solution for keeping intermediate files is to put cl.exe in the path and remove compiler-bindir from nvcc.profile. Logged as a bug to NVIDIA.
UPDATE:
The problem does not manifest in CUDA 7.0.