when you are linking, the order of your libraries and source files makes a difference. for example for your case, g++ -I/usr/local/cuda/include -L/usr/lib/nvidia-current -lOpenCL opencl.cpp functions defined in the OpenCL library might not be loaded, since there nothing before them asking for a look-up. however if you use, g++ opencl.cpp -I/usr/local/cuda/include -L/usr/lib/nvidia-current -lOpenCL then any … Read more
Sure ! (In the following, I assume that you already know how to deal with cimport and the interactions between .pxd and .pyx. If this is not completely the case, just ask and I will develop that part as well) The sample (grabbed from a C++ project of mine, but a C project would work … Read more
Interestingly, using -fdata-sections can make the literal pools of your functions, and thus your functions themselves larger. I’ve noticed this on ARM in particular, but it’s likely to be true elsewhere. The binary I was testing only grew by a quarter of a percent, but it did grow. Looking at the disassembly of the changed … Read more
Add the following as a additional linker option: /ignore:4099 This is in Properties->Linker->Command Line
If you declare your variable in the header file: #ifndef GLOBAL_H #define GLOBAL_H int foo = 0; #endif In every include of your header file or translation unit, a new instance of your integer is created. As you mentioned, to avoid this, you need to declare the item as “extern” in the header file and … Read more
Here’s an authoritative answer, from a MinGW project administrator. Your problem arises because you continue to use an obsolete, (no longer maintained; no longer supported), version of GCC. Current versions of mingwrt are compiled using GCC-4.x, (I used GCC-4.8.2 for mingwrt-3.21 and its descendants), and this introduces the dependencies on __chkstk_ms, (which is provided by … Read more
I was having this problem with an ncurses program on Centos 6.2. It turns out that ncurses is sometimes split into two libraries, ncurses and tinfo. In my case, stdscr exists in libtinfo, not in libncurses, so adding -ltinfo to the link line, after -lncurses, solved the problem.
The correct way is as follows: file1.c #include <stdio.h> #include “file2.h” int main(void){ printf(“%s:%s:%d \n”, __FILE__, __FUNCTION__, __LINE__); foo(); return 0; } file2.h void foo(void); file2.c #include <stdio.h> #include “file2.h” void foo(void) { printf(“%s:%s:%d \n”, __FILE__, __func__, __LINE__); return; } output $ $ gcc file1.c file2.c -o file -Wall $ $ ./file file1.c:main:6 file2.c:foo:6 $
C++ requires that an inline function definition be present in a translation unit that references the function. Template member functions are implicitly inline, but also by default are instantiated with external linkage. Hence the duplication of definitions that will be visible to the linker when the same template is instantiated with the same template arguments … Read more
You could do this: objcopy –input binary \ –output elf32-i386 \ –binary-architecture i386 my_file.xml myfile.o This produces an object file that you can link into your executable. This file will contain these symbols that you’ll have to declare in your C code to be able to use them 00000550 D _binary_my_file_xml_end 00000550 A _binary_my_file_xml_size 00000000 … Read more