I started experimenting with C/C++ the other day because I needed it for reading level-4 MAT-files without needing to purchase the Matlab editor or compiler. So I found just the library that I needed but I'm not familiar with C or C++ at all so I'm a beginner with those two languages. Anyhow I need to include the 'matio' library. I've tried many things but I've had no luck.
I right clicked on the C/C++ project > properties > C/C++ General > Paths & Symbols > GNU C and added the path to the matio library.
I also went to C/C++ Build > Settings > Tool settings > GCC C Compiler > Includes and added the path there aswell.
Since I'm not any good with makefiles yet I did not specify my own makefile, instead I chose a executable project.
When I try to build my project it complains about a function called 'Mat_Open' in the matio library. When I hover over it, it says "undefined reference to 'Mat_Open'" the header 'matio.h' seems to work fine but it can't refer to 'Mat_Open' for some reason.
How do I solve this?
EDIT:
Here is the whole build console output.
10:42:52 **** Incremental Build of configuration Debug for project Project ****
Info: Internal Builder is used for build
gcc -IC:/matio-1.5.2/src -O0 -g3 -Wall -c -fmessage-length=0 -o CComponent.o "..\\CComponent.c"
gcc -Xlinker -lm -o Project.exe CComponent.o -lC:/matio-1.5.2/src
c:/mingw(x64)/bin/../lib/gcc/x86_64-w64-mingw32/4.8.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lC:/matio-1.5.2/src
collect2.exe: error: ld returned 1 exit status
10:42:53 Build Finished (took 330ms)
This is not necessarily an answer but may be useful for a comparison.
First of all, where did you install it? If your using Linux or Mac OSX you will want to install in the system directories (not sure about Windows). I use OSX so in my makefile (by the way I use Qt):
LIBS += -L/usr/local/lib/ -lmatio
INCLUDEPATH += /usr/local/include
Then of course, in the *.h files of my source I use:
#include "matio.h"
But I assume you have already tried that?
Related
I'm trying to compile a simple unit test on my windows machine.
When I'm trying to compile my test I'm using the shared library flag.
gcc -c -L./bin/ -lcmocka .\Test.c .\src\some_module.c
gcc .\Test.o .\some_module.o -o main
But the second line throws this error:
undefined reference to `_cmocka_run_group_tests'
However, if I'm compiling using directly the cmocka.c file which I downloaded from their git it works fine:
gcc -c .\lib\cmocka.c .\Test.c .\src\some_module.c
gcc .\Test.o .\some_module.o .\cmocka.o
What am I doing wrong in the first compilation?
In addition, I would happy to understand the difference between the two compilations. Which one is the better practice?
Thank you
In order to compile your code, the compiler does not need to know where to look for the library. It's enough if the compiler "finds" the declarations of the functions which are usually in the header files provided by the library.
This step is done in the first line of your compilation procedure (maybe you need to specify the folder to the header files by adding -Ipath/to/headers/):
gcc -c .\Test.c .\src\some_module.c
The library itself is "combined" with your code during the linking step, which is done during your second compilation step. Here you need to specify the library (and its path via -Lpath/to/library, if the linker does not find the library on its own):
gcc .\Test.o .\some_module.o -o main -L./bin/ -lcmocka
You should definitely not use your second approach and compile the library by yourself.
Based on This Stackoverflow link I downloaded & installed glibc v2.29 in "/usr/local/glibc" path of Linux OS. Then based on this Stackoverflow link I tried to compile This Example, But I got following errors.
First Try Command:
gcc -Wall -g -o main main.c -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
First Try Error Log:
main.c:1:10: fatal error: threads.h: No such file or directory
#include <threads.h>
^~~~~~~~~~~
compilation terminated.
Second Try Command:
In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
Second Try Error Log:
/tmp/ccCNYemW.o: In function `main':
/home/.../main.c:14: undefined reference to `thrd_create'
/home/.../main.c:16: undefined reference to `thrd_join'
collect2: error: ld returned 1 exit status
So I don't know where is the problem. Please Help me.
First of all, don't put an alternate libc (or alternate version of your libc) in a path searched by the normal include and library search (both link-time and runtime library search) for your main system one. This is a recipe for disaster. Installing a different glibc in /usr/local/ does avoid clobbering your system one, but now you just have two installed in places where the same tools can see and use them.
To do this right, you really need a full separate toolchain (gcc, binutils) in some completely separate path (like ~/my_glibc_root/... or /opt/alt_glibc_root/...). I'm not sure if there's a recommended way to do this. The glibc build procedures in Linux From Scratch might be a good place to look for ideas. In theory it can be done in a single stage; I do that with musl libc in musl-cross-make by careful use of intermediate make rules in the gcc build system. But applying the same idea to glibc probably requires some extra care.
Second Try Command: In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
This command is almost correct. The thrd_create and thrd_join functions are defined in libpthread, which you didn't link against.
Add -pthread to your compile command, and the link should succeed.
P.S. R's advice of not installing alternate GLIBC into /usr/local is also a good one.
There are quite a few similar topics on SO regarding this but I have exhausted all the suggestions on 15 similar threads.
Upon running tutorial code utilizing the SDL library, the IDE is complaining of "undefined reference" to all functions pertaining to SDL.
Situation
Architecture: 64 bit
IDE: CodeBlocks 16.01
Compiler: GNU GCC
What I have tried to do
1) I told the compiler to find header under directory:
.....\i686-w64-mingw32\include\SDL2 using relative paths
I did NOT select \include NOR did I select .....\x86_64-w64-mingw32\include\SDL2
2) I told compiler to find library files under directory:
.....\i686-w64-mingw32\lib using relative paths
I did NOT select ....\lib NOR did I select .....\x86_64-w64-mingw32\lib
3) When linking the libraries, I included four libraries under the directory
....\i686-w64-mingw32\lib and NOT the other directories as mentioned above.
4) The order in which the libraries were linked are as follows:
SDL2main.lib
SDL2.lib
SDL2test.lib
5) I ensured that the properties of main.c were such that compile file was checked, link file was checked, and the belongs in targets debug and release were both checked.
Build log:
-------------- Build: Debug in Snake Game (compiler: GNU GCC Compiler)---------------
mingw32-g++.exe
-L......\Downloads\SDL2-devel-2.0.4-mingw\SDL2-2.0.4\i686-w64-mingw32\lib
-o "bin\Debug\Snake Game.exe" obj\Debug\main.o -lmingw32 ......\Downloads\SDL2-devel-2.0.4-mingw\SDL2-2.0.4\i686-w64-mingw32\lib\libSDL2main.a
......\Downloads\SDL2-devel-2.0.4-mingw\SDL2-2.0.4\i686-w64-mingw32\lib\libSDL2.a
obj\Debug\main.o: In function SDL_main':
C:/XXX/XXX/XXX/XXX/XXX/main.c:9: undefined
reference toSDL_WM_SetCaption'
The log goes on and on with undefined references.
Can anybody guide me in solving this linking problem?
There is no SDL_WM_SetCaption in SDL2. Your code is likely to be using older SDL 1.2. Either use correct library or modify your code e.g following https://wiki.libsdl.org/MigrationGuide
I need to get familiar with Eclipse-CDT (indigo) for the first time so created the the project "First" with first.c and first.h, and then created a static library project Staticlib with mylib.c. I
cannot get the projects to link using Build All (after cleaning all). The output is:
Building target: First
Invoking: MacOS X C Linker
gcc -static -L"/Users/nate/Eclipse Workspaces/cdtWorkspace/Staticlib/Debug" -L"/Users/nate/Eclipse Workspaces/cdtWorkspace/Staticlib/Release" -o "First" ./src/first.o
ld: library not found for -lcrt0.o
Any idea of how to fix this?
The problem was that I forgot the in's and out's of make. When I figured out what eclipse-cdt wanted in the make file and the correct syntax it all worked.
compilation options for cmake (on windows) for ARM target system but when I run configure it's starting compiler tests:
CMake Error at D:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
The C compiler "D:/Program Files/yagarto/bin/arm-none-eabi-gcc.exe" is not
able to compile a simple test program.
It fails with the following output:
Change Dir: D:/merge/complex/build/CMakeFiles/CMakeTmp
Run Build Command:D:/PROGRA~1/YAGART~1/bin/make.exe "cmTryCompileExec/fast"
D:/PROGRA~1/YAGART~1/bin/make.exe -f
CMakeFiles/cmTryCompileExec.dir/build.make
CMakeFiles/cmTryCompileExec.dir/build
make.exe[1]: Entering directory
`D:/merge/complex/build/CMakeFiles/CMakeTmp'
"D:/Program Files/CMake 2.8/bin/cmake.exe" -E cmake_progress_report
D:/merge/complex/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o
"D:/Program Files/yagarto/bin/arm-none-eabi-gcc.exe" -o
CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c
D:/merge/complex/build/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTryCompileExec
"D:/Program Files/yagarto/bin/arm-none-eabi-gcc.exe"
"CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o" -o cmTryCompileExec
-rdynamic
arm-none-eabi-gcc.exe: error: unrecognized option '-rdynamic'
make.exe[1]: *** [cmTryCompileExec] Error 1
Using Yagatdo 4.6.* cross-compilation toolchain
How can I skip this tests or fix -rdynamic error that I am getting?
You can set CMAKE_<LANG>_COMPILER_WORKS to true to suppress further compiler checks for that language.
set(CMAKE_C_COMPILER_WORKS 1)
You can skip the compiler checks by adding NONE to your project call:
project(<projectname> NONE)
but this can have pretty far-reaching effects. For full details, run
cmake --help-command project
I'm not familiar with ARM, so this is probably not your best option here. I guess you'd be better to see if there's a way to fix the -rdynamic flag.
EDIT:
It looks like this was identified as a bug which is effectively still unresolved. The comments in the bug report mention adding the following lines as a workaround (presumably before your project call):
set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "")
It seems you target actually something else than Linux, so you should tell cmake that you are cross-compiling for the generic case:
SET(CMAKE_SYSTEM_NAME Generic)
Followed by (optionally, but nice to specify):
SET(CMAKE_SYSTEM_PROCESSOR arm)
SET(CMAKE_CROSSCOMPILING 1)
However, if you specify (which you likely did because this is stated in a lot of examples online):
SET(CMAKE_SYSTEM_NAME Linux)
Then cmake will load the configuration files from (suppose version 2.8) the file:
/usr/share/cmake-2.8/Modules/Platform/Linux.cmake
from which it is likely to load:
/usr/share/cmake-2.8/Modules/Platform/Linux-GNU.cmake
Here the -rdynamic flag is set for historical reasons:
macro(__linux_compiler_gnu lang)
# We pass this for historical reasons. Projects may have
# executables that use dlopen but do not set ENABLE_EXPORTS.
set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-rdynamic")
endmacro()
Rather than disabling the tests as indeed is done by specifying NONE as the PROJECT argument, it seems setting the CMAKE_SYSTEM_NAME (to something else than Linux, for instance Generic) is what you actually want to do.
If you're just compiling a static library and you want to avoid having CMake test that the compiler can generate binaries, you can set the variable CMAKE_TRY_COMPILE_TARGET_TYPE.
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
When cross compiling for Windows, where there is no -rdynamic option, you can use
-DCMAKE_SYSTEM_NAME="Windows"
with cmake. Then Cmake will skip the test with -rdynamic.