i build a project on Eclipse using GCC Toolchain and arm-linux-gnueabi libraries
i have tow main issues using this codes attached (not my code, fft from ffmpeg with testcode to measure speed-error)
http://e2e.ti.com/cfs-file/__key/telligent-evolution-components-attachments/00-447-01-00-00-25-97-76/FFMPEG_5F00_FFT.zip
i have a C-code files with 2 .S files asm.S and neon_fft.S
i am not a software engineer but i understood that i use function keyword from asm.S file to use it in neon_fft.S
but it seems that project doesn't see the first file so i get the following error
Building file: ../src/fft_neon.S
Invoking: GCC Assembler
arm-linux-gnueabi-as -mcpu=cortex-a8 -mfpu=neon -I/usr/arm-linux-gnueabi/include -I/usr/arm-linux-gnueabi/include/asm -o "src/fft_neon.o" "../src/fft_neon.S"
../src/fft_neon.S: Assembler messages:
../src/fft_neon.S:34: Error: bad instruction `function fft4_neon'
../src/fft_neon.S:50: Error: bad instruction `endfunc'
also how can i get right configure.h file ?
The filename ends with a capital S. By convention, this indicates that the assembler source needs to be processed by the C preprocessor. If you use arm-linux-gnueabi-gcc instead of arm-linux-gnueabi-as then the file should assemble successfully.
Related
I am trying to compile a source file with icc compiler and MAGMAmic library. However I get the following error:
icc -c -o direct.o direct.c -O3 -openmp -DADD_ -Wall -DHAVE_MIC -I/opt/intel/mic/coi/include -I/usr/include/intel-coi -I/opt/intel/compilers_and_libraries_2017.2.174/linux/mkl/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/ipp/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/mkl/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/tbb/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/daal/include -I/home/dslavchev/install/magmamic-1.4.0/include -I/home/dslavchev/install/magmamic-1.4.0/contol
icc: command line remark #10411: option '-openmp' is deprecated and will be removed in a future release. Please use the replacement option '-qopenmp'
In file included from /home/dslavchev/install/magmamic-1.4.0/include/magma_types.h(134),
from /home/dslavchev/install/magmamic-1.4.0/include/magmablas_z.h(17),
from /home/dslavchev/install/magmamic-1.4.0/include/magmablas.h(12),
from /home/dslavchev/install/magmamic-1.4.0/include/magma.h(17),
from direct.c(21):
/opt/intel/compilers_and_libraries_2017.2.174/linux/compiler/include/complex(30): catastrophic error: cannot open source file "complex"
#include_next <complex>
^
The MAGMAmic library has compiled correctly and I can run it's test ok.
I have looked at the way testing_dgesv_mic.cpp example compiles and used the same includes and link, however in my case I get the above error.
I have added the following in my .bashrc file in order to get the Intel compilers' and libraries' enviromental variables:
#for MAGMA mic
export MAGMA_PATH=/home/dslavchev/install/magmamic-1.4.0
source /opt/intel/bin/compilervars.sh intel64
source /opt/intel/mkl/bin/mklvars.sh intel64
Any ideas what might cause icc to be unable to include the "complex" file?
The file complex really exists in "/opt/intel/compilers_and_libraries_2017.2.174/linux/compiler/include/complex"
icc vesrion is:
[dslavchev#sl051 results]$ icc -v
icc version 17.0.2 (gcc version 4.4.7 compatibility)
magmamic version is magmamic-1.4.0
EDIT: Removed unnecessary code comment
EDIT2: Added version info.
MAGMAmic is a C++ library and it cannot be used with C code directly.
When icc detects that you want to compile .c++ file it automatically switches to icpc (Intel C++ compiler) which in turn results in the above error.
Solution: Either switch to icpc or rename your files to .c++
This question was answered by mark on the MAGMA forums. Link:
http://icl.cs.utk.edu/magma/forum/viewtopic.php?f=2&t=1587&p=4442#p4442
I have created a mex function (more specifically, using CUDA)
the compilation was successful, and I got a mex file zMul.mexmaci64
but on the execution, matlab reported an error:
Invalid MEX-file '/Users/zlw/Documents/MATLAB/lowComplexity/cbased/matMulGPU/zMul.mexmaci64':
dlopen(/Users/zlw/Documents/MATLAB/lowComplexity/cbased/matMulGPU/zMul.mexmaci64, 1):
Library not loaded: #rpath/libcublas.6.0.dylib
Referenced from: /Users/zlw/Documents/MATLAB/lowComplexity/cbased/matMulGPU/zMul.mexmaci64
Reason: image not found
What should I do do solve it?
additional info
setting the environment vars (PATH,LD_LIBRARY_PATH,DYLD_LIBRARY_PATH) in Matlab and in .bash_profile doesn't work for me
I'm pretty sure that the environment vars are set correctly because when I created an alias to the dylib file, Matlab detected it, tried to load it, but failed with message:no suitable image found
Thanks!
Use otool -L in both Matlab and UNIX console.
In Matlab:
!otool -L /path/to/zMul.mexmaci64
In UNIX console:
otool -L /path/to/zMul.mexmaci64
Try to find the difference between them. If there is a difference in dependency, that is probably breaking the MEX binary. You might need to apply the same technique for the dependent dylib objects recursively. Typically, enforcing the one appearing in UNIX console using DYLD_INSERT_LIBRARIES solves the problem.
Another possibility is the C++ runtime compatibility. If you're using OS X Mavericks, you should check that your MEX command is using libc++ but not libstdc++ in mexopts.sh. Below is my configuration example in mexopts.sh:
CC='clang'
CXX='clang++'
SDKROOT='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/'
MACOSX_DEPLOYMENT_TARGET='10.9'
CFLAGS="$CFLAGS -Dchar16_t=uint16_t"
CXXFLAGS="$CXXFLAGS -std=c++11 -stdlib=libc++ -DCHAR16_T"
CXXLIBS="$MLIBS -lc++"
This post might help: http://www.seaandsailor.com/matlab-xcode6.html
It was easier than I thought. Just replace all 10.x with your OS X version and add -Dchar16_t=UINT16_T to CLIBS in mexopts.sh file.
I'm trying to use CUDA code inside MATLAB mex, under linux. With the "whole program compilation" mode, it works good for me. I take the following two steps inside Nsight:
(1) Add "-fPIC" as a compiler option to each .cpp or .cu file, then compile them separately, each producing a .o file.
(2) Set the linker command to be "mex" and add "-cxx" to indicate that the type of all the .o input files are cpp files, and add the library path for cuda. Also add a cpp file that contains the mexFunction entry as an additional input.
This works good and the resulted mex file runs well under MATLAB. After that when I need to use dynamical parallelism, I have to switch to the "separate compilation mode" in Nsight. I tried the same thing above but the linker produces a lot of errors of missing reference, which I wasn't able to resolve.
Then I checked the compilation and linking steps of the "separate compilation" mode. I got confused by what it is doing. It seems that Nsight does two compilation steps for each .cpp or .cu file and produces a .o file as well as a .d file. Like this:
/usr/local/cuda-5.5/bin/nvcc -O3 -gencode arch=compute_35,code=sm_35 -odir "src" -M -o "src/tn_matrix.d" "../src/tn_matrix.cu"
/usr/local/cuda-5.5/bin/nvcc --device-c -O3 -gencode arch=compute_35,code=compute_35 -gencode arch=compute_35,code=sm_35 -x cu -o "src/tn_matrix.o" "../src/tn_matrix.cu"
The linking command is like this:
/usr/local/cuda-5.5/bin/nvcc --cudart static --relocatable-device-code=true -gencode arch=compute_35,code=compute_35 -gencode arch=compute_35,code=sm_35 -link -o "test7" ./src/cu_base.o ./src/exp_bp_wsj_dev_mex.o ./src/tn_main.o ./src/tn_matlab_helper.o ./src/tn_matrix.o ./src/tn_matrix_lib_dev.o ./src/tn_matrix_lib_host.o ./src/tn_model_wsj_dev.o ./src/tn_model_wsj_host.o ./src/tn_utility.o -lcudadevrt -lmx -lcusparse -lcurand -lcublas
What's interesting is that the linker does not take the .d file as input. So I'm not sure how it dealt with these files and how I should process them with the "mex" command when linking?
Another problem is that the linking stage has a lot of options I don't understand (--cudart static --relocatable-device-code=true), which I guess is the reason why I cannot make it work like in the "whole program compilation" mode. So I tried the following:
(1) Compile in the same way as in the beginning of the post.
(2) Preserve the linking command as provided by Nsight but change to use "-shared" option, so that the linker produces a lib file.
(3) Invoke mex with input the lib file and another cpp file containing the mexFunction entry.
This way mex compilation works and it produces a mex executable as output. However, running the resulted mex executable under MATLAB produces a segmentation fault immediately and crashes MATLAB.
I'm not sure if this way of linking would cause any problem. More strangely, I found that the mex linking step seems to finish trivially without even checking the completeness of the executable, because even if I miss a .cpp file for some function that the mexFunction will use, it still compiles.
EDIT:
I figured out how to manually link into a mex executable which can run correctly under MATLAB, but I haven't figured out how to do that automatically under Nsight, which I can in the "whole program compilation" mode. Here is my approach:
(1) Exclude from build the cpp file which contains the mexFunction entry. Manually compile it with the command "mex -c".
(2) Add "-fPIC" as a compiler option to each of the rest .cpp or .cu file, then compile them separately, each producing a .o file.
(3) Linking will fail because it cannot find the main function. We don't have it since we use mexFunction and it is excluded. This doesn't matter and I just leave it there.
(4) Follow the method in the post below to manually dlink the .o files into a device object file
cuda shared library linking: undefined reference to cudaRegisterLinkedBinary
For example, if step (2) produces a.o and b.o, here we do
nvcc -gencode arch=compute_35,code=sm_35 -Xcompiler '-fPIC' -dlink a.o b.o -o mex_dev.o -lcudadevrt
Note that here the output file mex_dev.o should not exist, otherwise the above command will fail.
(5) Use mex command to link all the .o files produced in step (2) and step (4), with all necessary libraries supplied.
This works and produces runnable mex executable. The reason I cannot automate step (1) inside Nsight is because if I change the compilation command to "mex", Nsight will also use this command to generate a dependency file (the .d file mentioned in the question text). And the reason I cannot automate step (4) and step (5) in Nsight is because it involves two commands, which I don't know how to put them in. Please let me know if you knows how to do these. Thanks!
OK, I figured out the solution. Here are the complete steps for compiling mex programs with "separate compilation mode" in Nsight:
Create a cuda project.
In the project level, change build option for the following:
Switch on -fPIC in the compiler option of "NVCC compiler" at the project level.
Add -dlink -Xcompiler '-fPIC' to "Expert Settings" "Command Line Pattern" of the linker "NVCC Linker"
Add letter o to "Build Artifact" -> "Artifact Extension", since by -dlink in the last step we are making the output a .o file.
Add mex -cxx -o path_to_mex_bin/mex_bin_filename ./*.o ./src/*.o -lcudadevrt to "Post Build Steps", (add other necessary libs)
UPDATE: In my actual project I moved the last step to a .m file in MATLAB, because otherwise if I do it while my mex program is running, it could cause MATLAB crash.
For files needs to be compiled with mex, change these build option for each of them:
Change the compiler to GCC C++ Compiler in Tool Chain Editor.
Go back to compiler setting of GCC C++ Compiler and change Command to mex
Change command line pattern to ${COMMAND} -c -outdir "src" ${INPUTS}
Several additional notes:
(1) Cuda specific details (such as kernel functions and calls to kernel functions) must be hidden from the mex compiler. So they should be put in the .cu files rather than the header files. Here is a trick to put templates involving cuda details into .cu files.
In the header file (e.g., f.h), you put only the declaration of the function like this:
template<typename ValueType>
void func(ValueType x);
Add a new file named f.inc, which holds the definition
template<>
void func(ValueType x) {
// possible kernel launches which should be hidden from mex
}
In the source code file (e.g., f.cu), you put this
#define ValueType float
#include "f.inc"
#undef ValueType
#define ValueType double
#include "f.inc"
#undef ValueType
// Add other types you want.
This trick can be easily generalized for templated classes to hide details.
(2) mex specific details should also be hidden from cuda source files, since the mex.h will alter the definitions of some system functions, such as printf. So including of "mex.h" should not appear in header files that can potentially be included in the cuda source files.
(3) In the mex source code file containing the entry mexFunction, one can use the compiler macro MATLAB_MEX_FILE to selectively compile code sections. This way th source code file can be compiled into both mex executable or ordinarily executable, allowing debugging under Nsight without matlab. Here is a trick for building multiple targets under Nsight: Building multiple binaries within one Eclipse project
First of all, it should be possible to set up Night to use a custom Makefile rather than generate it automatically. See Setting Nsight to run with existing Makefile project.
Once we have a custom Makefile, it may be possible to automate (1), (4), and (5). The advantage of a custom Makefile is that you know exactly what compilation commands will take place.
A bare-bones example:
all: mx.mexa64
mx.mexa64: mx.o
mex -o mx.mexa64 mx.o -L/usr/local/cuda/lib64 -lcudart -lcudadevrt
mx.o: mxfunc.o helper.o
nvcc -arch=sm_35 -Xcompiler -fPIC -o mx.o -dlink helper.o mxfunc.o -lcudadevrt
mxfunc.o: mxfunc.c
mex -c -o mxfunc.o mxfunc.c
helper.o: helper.c
nvcc -arch=sm_35 -Xcompiler -fPIC -c -o helper.o helper.c
clean:
rm -fv mx.mexa64 *.o
... where mxfunc.c contains the mxFunction but helper.c does not.
EDIT: You may be able achieve the same effect in the automatic compilation system. Right click on each source file and select Properties, and you'll get a window where you can add some compilation options for that individual file. For linking options, open Properties of the project. Do some experiments and pay attention to the actual compilation commands that show up in the console. In my experience, custom options sometimes interact with the automatic system in a weird way. If this method proves too troublesome for you, I suggest that you make a custom Makefile; this way, at least we are not caught by unexpected side-effects.
I am using Eclipse Juno with GCC compiler for C code. I am trying to use gcno plugin to get code coverage.
of course I added -ftest-coverage -fprofile-arcs to the compiler and the linker flags.
But, when I click on profiling tools for code coverage I get the error in the image below:
"Recompile at least one of your C/C++ source files with the
"-fprofile-arcs" and "-ftest-coverage" options and link your
executable with "-lgcov". If you compile and link in a single gcc
call, you can use the gcc "--coverage" option. "
Please I need help with this error.
In order to use the gcov code coverage results you must not only compile with the compiler and linker flags you mentions, but you must also either run a unit test or run your program to gather the data. Gcov gathers the data as the points in your code are reached. If you do not run the program you will not generate any data.
I am using Windows XP and matlab version is 7.10.0.
I have the levmar(Levenberg Marquardt) package from http://www.ics.forth.gr/~lourakis/levmar/levmar-2.5.tgz
In the README file, we are told to compile in matlab using mex using the following command:
mex -DHAVE_LAPACK -I.. -O -L -L levmar.c -llevmar -lclapack -lblas -lf2c.
I downloaded lapack.lib , blas.lib and f2c.lib for windows
UPDATE:
The original error got resolved after I built a vc project file given in the package.
But now there are some error messages like :
levmar.lib(misc.obj) : error LNK2019: unresolved external symbol _dgemm_ referenced in function _dlevmar_trans_mat_mat_mult
Did you create a file with a mex-function gateway? You can't just compile a c-function for Matlab; you need to do a little bit of work to take care of the I/O between Matlab and the c-code.
If you follow the steps outlined in this document, you should do fine.
You may have a look at immoptibox, which comprises Levenberg-Marquardt algorithm as well.
I just figured it out after searching a while and noticed that the levmar package included a vc project file which i needed to build and it created a file called levmar.lib .
But now I am getting some errors which involves messages like 'unable to resolve external symbols'