I realize a CMSIS Project solution with VS Code but I've an error on an include file :
#include "stm32f10x.h"
And I've got this error :
In included file: "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"clang(pp_hash_error)
core_cm3.h(90, 6): Error occurred here
The path of this file is here :
C:\Users\"name"\AppData\Local\Arm\Packs\Keil\STM32F1xx_DFP\2.4.0\Device\Include
But I think I forgot something during the configuration.
I justa want to build my C file but VS code doesn't make the link between my .h and my CMSIS project.
You are never supposed to #include "stm32f10x.h"
You only #include "stm32f1xx.h" and it will include the other headers you need.
You must also define a macro on the command line, one of STM32F101x6, STM32F101xB, STM32F101xE or STM32F101xG.
For most compilers you can define this with an argument like -DSTM32F101xB.
After that you will need particular command line arguments that match your chosen processor, such as -mthumb -mcpu=cortex-m3 -mfpu=none.
Maybe your error was specifying an incorrect -mfpu=.
Related
I have written a programm in C and GTK3. I am using Arch Linux and everything works fine. However, I have to use my program also on a rather old Ubuntu machine.
gtk+-3.0 3.10.8
GCC 4.8.4
With this setup the program does not compile
In the Header file of a custom GTK-Widget I have:
#ifndef __LAYER_ELEMENT_H__
#define __LAYER_ELEMENT_H__
#include <gtk/gtk.h>
G_BEGIN_DECLS
G_DECLARE_FINAL_TYPE(LayerElement, layer_element, LAYER, ELEMENT, GtkListBoxRow)
/* Rest of file comes here */
When compiling it throws the error message:
expected ')' before GtkListBoxRow in the line with the G_DECLARE_FINAL_TYPE macro.
How can I fix this issue?
G_DECLARE_FINAL_TYPE was added to GLib in version 2.44 (see the documentation). If you want to compile on an old version of Ubuntu, you will either have to get hold of a backport of GLib 2.44 (or later) for that version of Ubuntu, and compile against that; or you will have to modify your code to not use any GLib APIs added after version 2.40.
I'm having trouble using the CUDA Thrust library in MATLAB MEX code.
I have an example that runs fine externally, but if I compile and run it as a MEX file, it produces "missing symbol" errors at runtime.
It seems specific to the Thrust library. If instead of thrust::device_vector I use cudaMalloc with cudaMemcpy or cublasSetVector then everything is fine.
Minimum example
thrustDemo.cu:
#ifdef MATLAB_MEX_FILE
#include "mex.h"
#include "gpu/mxGPUArray.h"
#endif
#include <thrust/device_vector.h>
#include <vector>
void thrustDemo() {
std::vector<double> foo(65536, 3.14);
thrust::device_vector<double> device_foo(foo);
}
#ifdef MATLAB_MEX_FILE
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, mxArray const *prhs[]) {
thrustDemo();
}
#else
int main(void) { thrustDemo(); }
#endif
The problem
I can compile this from the command line (nvcc thrustDemo.cu) and run the resulting executable just fine.
When I try to build this as a MATLAB MEX file (mexcuda thrustDemo.cu from within MATLAB R2017a), it compiles and links just fine:
>> mexcuda thrustDemo.cu
Building with 'nvcc'.
MEX completed successfully.
But when I try to run it, I get the following error:
>> thrustDemo()
Invalid MEX-file '/home/kqs/thrustDemo.mexa64':
Missing symbol '_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5c_strEv' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5emptyEv' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt12length_errorC1EPKc' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt13runtime_errorC2EPKc' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEPKc' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1ERKS4_' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1Ev' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEpLEPKc' required by '/home/kqs/thrustDemo.mexa64'
Missing symbol '_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEpLERKS4_' required by '/home/kqs/thrustDemo.mexa64'.
This is pretty foreign to me; can somebody tell me what this means? These look like linker errors, but they're being generated at runtime. Also, I thought Thrust was a template library, so what is there to link to?
And finally, replacing thrust::device_vector with cudaMalloc and either cudaMemcpy or cublasSetVector works just fine. So for now I'm stuck with a bunch of cudaMalloc in my code, which seems...distasteful. I'd really like to be able to use Thrust.
Versions
MATLAB R2017a
nvcc V8.0.61, gcc 5.4.0, Ubuntu 16.04.2
NVidia driver 375.39, GTX 1060 graphics card (Compute Capability 6.1)
Update: ldd output
Per comments, I checked the dependencies of the MEX file using ldd thrustDemo.mexa64:
linux-vdso.so.1 => (0x00007ffdd35ea000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f097eccf000)
libcudart.so.8.0 => /usr/local/cuda-8.0/targets/x86_64-linux/lib/libcudart.so.8.0 (0x00007f097ea69000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f097e852000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f097e489000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f097e180000)
/lib64/ld-linux-x86-64.so.2 (0x0000562df178c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f097df7b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f097dd5e000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f097db56000)
I tried looking for one of these missing symbols, and was able to find it:
$ nm -D /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep "_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5c_strEv"
0000000000120be0 W _ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE5c_strEv
So it seems that MATLAB must be looking in the wrong place.
It turns out this has nothing to do with Thrust but is rather an issue with MATLAB having its own version of the C++ standard libraries.
Thanks to #Navan and #talonmies for their helpful comments.
Interpreting the error
First, MATLAB is raising these errors when it's loading the MEX file. The MEX file has external dependencies, and MATLAB could not find them.
After checking these dependencies with the Linux utility ldd, then using nm to list the symbols define by these libraries, I found that the system version of the libstdc++ shared library actually contains these "missing symbols". Hence why the externally-compiled version works just fine.
Solving the issue
The root problem, then, is that MATLAB ships with its own, older version of libstdc++ that is lacking these functions. Knowing the root cause, I found questions like these:
How to tell mex to link with the libstdc++.so.6 in /usr/lib instead of the one in the MATLAB directory?
Version GLIBCXX_3.4.11 not found (required by buildW.mexglx)
which describe workarounds that were indeed successful for my problem.
In particular, I used LD_PRELOAD when launching MATLAB to force MATLAB to use the system libstdc++ instead of its own copy:
$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/local/MATLAB/R2017a/bin/matlab
Update: a better solution
It turns out that the folks at GCC are well aware of this incompatibility and discuss it here:
In the GCC 5.1 release libstdc++ introduced a new library ABI that includes new implementations of std::string and std::list. These changes were necessary to conform to the 2011 C++ standard which forbids Copy-On-Write strings and requires lists to keep track of their size.
In order to maintain backwards compatibility for existing code linked to libstdc++ the library's soname has not changed and the old implementations are still supported in parallel with the new ones.
...
The _GLIBCXX_USE_CXX11_ABI macro (see Macros) controls whether the declarations in the library headers use the old or new ABI.
To tell gcc to use the older ABI, we just need to define _GLIBCXX_USE_CXX11_ABI as 0 before we include any library headers, e.g. by passing a -D option to the compiler:
-D_GLIBCXX_USE_CXX11_ABI=0
For the sake of completeness, I'll mention that my full mexcuda call looks like this:
nvcc_opts = [...
'-gencode=arch=compute_30,code=sm_30 ' ...
'-gencode=arch=compute_50,code=sm_50 ' ...
'-gencode=arch=compute_60,code=sm_60 ' ...
'-std=c++11 ' ...
'-D_GLIBCXX_USE_CXX11_ABI=0 ' % MATLAB's libstdc++ uses old library ABI
];
mexcuda_opts = {
'-lcublas' % Link to cuBLAS
'-lmwlapack' % Link to LAPACK
'-lcufft' % Link to cuFFT
['NVCCFLAGS="' nvcc_opts '"']
'-L/usr/local/cuda/lib64' % Location of CUDA libraries
};
mexcuda(mexcuda_opts{:}, src_file);
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.
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 have a program that performs some network IO that compiles a 32 bit binary just fine
However, when I set the -m64 option at compile time I get the following rather cryptic error
In file included from /usr/include/sys/stream.h:22,
from /usr/include/netinet/in.h:62,
from /usr/include/sys/socket.h:221,
from operation_networkio.cc:15:
/usr/include/sys/vnode.h:241: error: overflow in array dimension
/usr/include/sys/vnode.h:241: error: size of array `pad' is too large
the offending lines in my source code operation_networkio.cc that are triggering this error in my program seem to be
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
could someone enlighten me what I am doing wrong and how to cure this ?
I'm using GCC on Solaris sparc
eventually found that I had -mfaster-structs option enabled on the compilation.
For some reason removing this option cures this build problem. that causes a 64 bit build to fail, though a 32 bit build works.
If someone could explain it I'd certainly like to know why
This is indeed weird.
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/sys/vnode.h#286
It should not be possible that these data structures grow beyond 64 bytes. Or maybe you included some files that redefine these data structures. To be sure what the cause is, you should look at the preprocessed output from the C compiler.
g++ -E operation_networkio.cc -I... -D... -o preprocessed.cc
After running that command you should have a look at the file preprocessed.cc. Search for vn_vfslocks_entry and see if the code around that definition is what you expect.