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
Related
I'm using OSX command line gcc and attempting to build a dynamic library. when I do the build I get the following warning. How is it it is not finding this library given /usr/lib is well known? And /usr/lib does indeed exist on my machine
this is what I am using:
gcc -arch i386 cata/*.c -dynamiclib -o build/cata.dylib -LC_ID_DYLIB=/usr/lib
Thanks
the way i solved it was to make it so the string that got stuck in the library (on where to find the library at runtime) was relative to nowhere -- if that makes sense. so it would be forced to use the LD_LOAD_PATH.
I was using the other flags because someone suggested I use them.
so the gcc i ended up using is this:
# my tree is like this
# cata/*.c
# build/*.dylib
#
cd build
gcc -arch i386 ../cata/*.c -dynamiclib -o cata.dylib
Doing this compiles/makes a library in the same directory where it thinks it is 'used' (basically having no path). I am now free to put it somewhere else. When it is later linked at compile time by a different program and then examined using
otool -L
it appears with no path in front of the library name. This is apparently preferable as now when the system goes to try to find it it resorts to looking at the standard libraries and eventually finds it (because I install it to one of the standard locations).
In the original way, otool -L was showing it having a required path of
'build/cata.dylib'
This made it un-findable and which is why i was trying to use the apple documentation to get around the problem.
This doesn't really solve why LC_ID_DYLIB doesn't work. I looked into the Loader.h file (line 643) and it has room for an identifier(0xd), a path, and a structure, so I don't really understand why my path wasn't getting picked up. but its two different topics. Loader.h is runtime and the other is gcc AFAIK. I'm still learning apple.
I am fairly new to this, but I will try to provide as detailed information as possible. I initially tried to provide a screenshot, but I can't do so without 10 reputation, so I am going to copy+paste the error messages as text at the bottom.
I am working on the Harvard CS50 Problem Set 1. As part of that, you are supposed to use a library provided for the coursework. It comes in two files: cs50.h and cs50.c
I have downloaded these files and initially I was getting an error, which I found was because it's a 32-bit library and I'm running 64-bit. I changed where I was referencing the libraries by going to the Project > Build Phases > Link Binary with Libraries, as what I found online indicated that if I handled it here, Xcode would take care of ensuring the correct architecture and such (32-bit vs. 64-bit).
Now I am getting the yellow errors stating that it is passing over these files when I try to build because it is an unexpected file type.
I found a recommendation to use the File Inspector to view the type and I rotated through the various C file types available to see if it would fix anything and I had no luck.
I also found another conversation around this that indicated updating the architecture type to the Universal option would help, but that has not changed anything.
At this point, I am unable to find anything that seems related to my problem through Google searches.
I also realize that due to my newness, I have just done something royally stupid, but I feel I have spend a lot of time trying to fix this. I appreciate any help.
warning: skipping file '/Users/matthewcanova/Documents/include/cs50.h' (unexpected file type 'sourcecode.c.h' in Frameworks & Libraries build phase)
warning: skipping file '/Users/matthewcanova/Documents/include/cs50.c' (unexpected file type 'sourcecode.c.c' in Frameworks & Libraries build phase)
Warning: skipping file '/Users/matthewcanova/Documents/include/cs50.h' (unexpected file type 'sourcecode.c.h' in Frameworks & Libraries build phase)
Warning: skipping file '/Users/matthewcanova/Documents/include/cs50.c' (unexpected file type 'sourcecode.c.c' in Frameworks & Libraries build phase)
Ld /Users/matthewcanova/Library/Developer/Xcode/DerivedData/Problem_Set_1- hkvfcrlbsfojiafrcnafkxgoannu/Build/Products/Debug/Problem\ Set\ 1 normal x86_64
cd "/Users/matthewcanova/Documents/Problem Set 1"
export MACOSX_DEPLOYMENT_TARGET=10.9
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -L/Users/matthewcanova/Library/Developer/Xcode/DerivedData/Problem_Set_1-hkvfcrlbsfojiafrcnafkxgoannu/Build/Products/Debug -F/Users/matthewcanova/Library/Developer/Xcode/DerivedData/Problem_Set_1-hkvfcrlbsfojiafrcnafkxgoannu/Build/Products/Debug -filelist /Users/matthewcanova/Library/Developer/Xcode/DerivedData/Problem_Set_1-hkvfcrlbsfojiafrcnafkxgoannu/Build/Intermediates/Problem\ Set\ 1.build/Debug/Problem\ Set\ 1.build/Objects-normal/x86_64/Problem\ Set\ 1.LinkFileList -mmacosx-version-min=10.9 -Xlinker -dependency_info -Xlinker /Users/matthewcanova/Library/Developer/Xcode/DerivedData/Problem_Set_1-hkvfcrlbsfojiafrcnafkxgoannu/Build/Intermediates/Problem\ Set\ 1.build/Debug/Problem\ Set\ 1.build/Objects-normal/x86_64/Problem\ Set\ 1_dependency_info.dat -o /Users/matthewcanova/Library/Developer/Xcode/DerivedData/Problem_Set_1-hkvfcrlbsfojiafrcnafkxgoannu/Build/Products/Debug/Problem\ Set\ 1
Undefined symbols for architecture x86_64:
"_GetInt", referenced from:
_getPyramidHeight in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Those are source code files, that need to be compiled with the application you build.
From what you say, it looks like you are trying to link those files as if they were already compiled.
You should remove them from the "Link Binary with Libraries" phase and add the '.c' file to the "Compile source" phase of your project (only the '.c' file, because only this file actually contains code that needs to be compiled. The '.h' file is a file meant to inform others of the interface of the functions provided by that code)
This is basically what the linker is trying to tell you in the warnings: it is confused to find source-code files at this phase of building
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?
My build environment is CentOS 5. I have a third party library called libcunit. I installed it with autotools and it generates both libcunit.a and libcunit.so. I have my own application that links with a bunch of shared libraries. libcunit.a is in the current directory and libcunit.so and other shared libraries are in /usr/local/lib/. When I compile like:
gcc -o test test.c -L. libcunit.a -L/usr/local/lib -labc -lyz
I get a linkage error:
libcunit.a(Util.o): In function `CU_trim_left':
Util.c:(.text+0x346): undefined reference to `__ctype_b'
libcunit.a(Util.o): In function `CU_trim_right':
Util.c:(.text+0x3fd): undefined reference to `__ctype_b'
But when I compile with .so like:
gcc -o test test.c -L/usr/local/lib -lcunit -labc -lyz
it compiles fine and runs fine too.
Why is it giving error when linked statically with libcunit.a?
Why is it giving error when linked statically with libcunit.a
The problem is that your libcunit.a was built on an ancient Linux system, and depends on symbols which have been removed from libc (these symbols were used in glibc-2.2, and were removed from glibc-2.3 over 10 years ago). More exactly, these symbols have been hidden. They are made available for dynamic linking to old binaries (such as libcunit.so) but no new code can statically link to them (you can't create a new executable or shared library that references them).
You can observe this like so:
readelf -Ws /lib/x86_64-linux-gnu/libc.so.6 | egrep '\W__ctype_b\W'
769: 00000000003b9130 8 OBJECT GLOBAL DEFAULT 31 __ctype_b#GLIBC_2.2.5
readelf -Ws /usr/lib/x86_64-linux-gnu/libc.a | egrep '\W__ctype_b\W'
# no output
Didn't notice that the libcunit.a is actually found in your case and the problem with linakge is rather in the CUnit library itself. Employed Russian is absolutely right, and he's not talking about precompiled binary here. We understand that you've built it yourself. However, CUinit itself seems to be relying on the symbol from glibc which is not available for static linking anymore. As a result you have only 2 options:
File a report to the developers of CUnit about this and ask them to fix it;
Use dynamic linking.
Nevertheless, my recommendation about your style of static linkage still applies. -L. is in general bad practice. CUnit is a 3rd party library and should not be placed into the directory containing source files of your project. It should be rather installed in the same way as the dynamic version, i.e. like you have libcunit.so in /usr/local/lib. If you'd supply prefix to Autotools on the configure stage of CUnit, then Autotools would install everything properly. So if you want to link statically with CUnit, consider doing it in the following form:
gcc -o test test.c -L/usr/local/lib -Wl,-Bstatic -lcunit -Wl,-Bdynamic -labc -lyz
I am attempting to cross-compile on AIX with the xlc/xlC compilers.
The code compiles successfully when it uses the default settings on another machine. The code actually successfully compiles with the cross-compilation, but the problem comes from the linker. This is the command which links the objects together:
$(CHILD_OS)/usr/vacpp/bin/xlC -q32 -qnolib -brtl -o $(EXECUTABLE) $(OBJECT_FILES)
-L$(CHILD_OS)/usr/lib
-L$(CHILD_OS)/usr/vacpp/lib/profiled
-L$(CHILD_OS)/usr/vacpp/lib
-L$(CHILD_OS)/usr/vac/lib
-L$(CHILD_OS)/usr/lib
-lc -lC -lnsl -lpthread
-F$(CHILD_OS)$(CUSTOM_CONFIG_FILE_LOCATION)
When I attempt to link the code, I get several Undefined symbols:
.setsockopt(int,int,int,const void*,unsigned long), .socket(int,int,int), .connect(int,const sockaddr*,unsigned long), etc.
I have discovered that the symbols missing are from the standard c library, libc.a. When I looked up the symbols with nm for the libc.a that is being picked up, the symbols do indeed exist. I am guessing that there might be a problem with the C++ being unable to read the C objects, but I am truly shooting in the dark.
Sound like it might be a C++ name mangling problem.
Run nm on the object files to find out the symbols that they are looking for. Then compare the exact names against the libraries.
Then check the compilation commands, to ensure that the right version of the header files is being included - maybe it's including the parent OS's copy by mistake?
I was eventually able to get around this. It looks like I was using the C++ compiler for .c files. Using the xlc compiler instead of the xlC compiler for C files fixed this problem.