I am struggling with the issue while linking my code against libmagic:
test.c:(.text+0x16): undefined reference to `magic_open'
test.c:(.text+0x50): undefined reference to `magic_load'
test.c:(.text+0x60): undefined reference to `magic_error'
test.c:(.text+0x84): undefined reference to `magic_close'
test.c:(.text+0x9e): undefined reference to `magic_file'
test.c:(.text+0xba): undefined reference to `magic_close'
collect2: ld returned 1 exit status
However the issue appears only when gcc version > 4.4. To compile, I am using the the following command:
gcc -L/usr/lib/ -lmagic test.c -o test
An example code that uses libmagic might be found here. I have checked and this issue appears as well. Obviously the libmagic and libmagic-dev are installed on my system (Ubuntu 14.04).
Is there any way of handling this issue different thant downgrading gcc version?
This is a FAQ, unrelated to your version of GCC.
I don't think that your compilation succeeded with gcc-4.3
Order of arguments to gcc matter a lot (see e.g. this); object files and libraries should go last (from the high-level to the low-level ones). Try with
gcc -Wall -g test.c -lmagic -o mytest
BTW, don't call your executable test (but e.g. mytest) since test is often a shell builtin.
Related
Until some weeks ago, using the boost_regex library I used to compile a C++ file test.cpp using the following command.
g++-4.9 -Wall -O3 -march=native -flto -DNDEBUG -o test \
--std=c++14 test.cpp -lboost_regex -pthread
The compilation was working perfectly. But at some point, I needed to upgrade my OS (more precisely, it was Ubuntu 14.04, now it is Ubuntu 16.04).
I kept my local folders with my data, and I also installed the Boost library again in the new system, including boost_regex.
The Boost version in the new system is 1.58, unfortunately I cannot know which Boost version I was using before because it is now deleted.
I try to compile again the same file in the new system, with the same command as above, and the linker says it cannot find two functions called maybe_assign and construct_init. If I replace the -o test option with just -c (i.e. without linking) then the program is compiled without errors.
More precisely, when I try to do linking I get the following errors (they were extremely long, I hade to shorten using ... dots).
In function `boost::re_detail::perl_matcher<...>::match_match()':
undefined reference to `boost::match_results<...>::maybe_assign(boost::match_results<...> const&)'
In function `bool boost::regex_search<...>(...)':
undefined reference to `boost::re_detail::perl_matcher<...>::construct_init(...)'
In function `boost::re_detail::perl_matcher<...>::match_prefix()':
undefined reference to `boost::match_results<...>::maybe_assign(boost::match_results<...> const&)'
collect2: error: ld returned 1 exit status
I really don't know how this is possible, the libraries seem perfectly installed, nothing seems missing, and the compilation was working with a previous OS installation (then I guess older libraries).
At these point my only guess could be that Boost authors removed such functions? (maybe they are obsolete?). But I didn't find any trace of this on internet. If this is the case, how can I know the boost versions in which such functions are available?
Am I doing any mistake? Do you have any suggestions to investigate about this?
TL;DR use gcc5.
Ununtu 16.04 comes with gcc5 by default. Every C++ library in it is compiled with that compiler.
Now there was an incompatible C++ ABI change between gcc4 and gcc5. It made binaries built from C++ sources with gcc4 incompatible by default with binaries built with gcc5. This incompatibility often manifests itself as a bunch of undefined symbols that reference std::string and/or std::list.
The standard library comes built with a dual ABI to support objects built with older compilers. Other libraries like boost, hovever, don't.
I am getting below linking error while compiling a simple piece of code using pthread.
The system i am working on is x86_64 (gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) and am compiling as -
gcc -lpthread ~/temp/temp.cpp -lrt -L"/usr/lib/x86_64-redhat-linux5E/lib64/".
Its evident that the problem is with pthread library. So i have two questions.
Q1. is it fine to use x64 pthread libs with x86 code. (In this piece of code it doesnt matter but it does in my usage) (I guess its not but how might i differentiate between x64 and x86 libs?)
Q2. i see pthread and lrt both are present at /usr/lib but even if i give that path it says -lpthread not found.
What am i missing here? Thanks for your help.
Error :
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function `_start':
(.text+0x12): undefined reference to `__libc_csu_fini'
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o: In function `_start':
(.text+0x19): undefined reference to `__libc_csu_init'
/tmp/cc2GQOUf.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
Code :
#include <stdio.h>
#include <pthread.h>
int main()
{
pthread_t f1_thread;
return 0;
}
In compilation phase,compiler can use gcc or g++,but g++ will call gcc command automatically.But in link phase,linker can use g++ or gcc -lstdc++.Because the gcc command cannot link with the libraries that be used by c++ program automatically, so usually use g++to complete the link.
So the command g++ -g -lpthread ~/temp/temp.cpp -o temp should be ok.
There are two link errors in this project.
The first, pointed out by #Steve, is the lack of
void *__gxx_personality_v0;
If anyone can explain why a C++ project compiled with clang++3.5 under cygwin would create a reference to this, I would like to understand. Anyway, I defined the symbol as a workaround.
The other problem appears to be references to 32-bit relative addressing in 64-bit. I am looking for a way to tell clang++ to compile 32 bit or 64 bit. I will try on native linux as well, but again, if anyone can explain why this is happening, I would like to understand.
I am thinking it might be a static variable, located down low in the address space, being accessed by something on the stack, but again, clang is generating everything so as far as I can see, this is a bug in the compiler.
clang++ -std=c++11 -O2 -g -I include/ -pthread -c RequestHandler.cc
clang++ -std=c++11 -O2 -g Config.o Logger.o RequestHandler.o FileSys.\
o Buffer.o server.o CspServlet.o -pthread -o server
RequestHandler.o:fake:(.debug_info+0x54bd): relocation truncated to f\
it: R_X86_64_32 against `.debug_ranges'
...
FileSys.o:fake:(.eh_frame$_ZNSt10_HashtableISsSt4pairIKSsP2FLESaIS4_E\
NSt8__detail10_Select1stESt8equal_toISsESt4hashISsENS6_18_Mod_range_h\
ashingENS6_20_Default_ranged_hashENS6_20_Prime_rehash_policyENS6_17_H\
ashtable_traitsILb1ELb0ELb1EEEE21_M_insert_unique_nodeEmmPNS6_10_Hash\
_nodeIS4_Lb1EEE+0x13): undefined reference to `__gxx_personality_v0'
FileSys.o:fake:(.eh_frame$_ZNSt8__detail16_Hashtable_allocISaINS_10_H\
ash_nodeISt4pairIKSsP2FLELb1EEEEE16_M_allocate_nodeIJRKS6_EEEPS7_DpOT\
_+0x13): more undefined references to `__gxx_personality_v0' follow
collect2: error: ld returned 1 exit status
Ok, it turns out that on cygwin, when I installed clang, it doesn't fully use the clang toolchain. clang is compiling, but g++ is linking (I think). Bear in mind all these tools could be aliased to something else, but it's very suspicious.
I built on Unix and it worked. Same makefile.
So the problem is that when I wrote clang, it wasn't using clang to link. And that is weird.
I installed GtkD from AUR, and now I'm trying to compile this tutorial code. Both for compiling GtkD itself and the tutorial code, I'm using GDC 4.9.1.
I attempted to compile the code as follows (hello.d is the file name):
gdc -Wall -Werror -Wdeprecated -Wunknown-pragmas -g -m64 `pkg-config --cflags --libs gtkd-2` -O3 -frelease -o hello
But when I try that, I get this:
/tmp/ccxejYOB.o: In function `_Dmain':
/home/koz/Documents/Programming/D/gtkd/hello.d:23: undefined reference to `_D3gtk4Main4Main4initFKAAyaZv'
/home/koz/Documents/Programming/D/gtkd/hello.d:24: undefined reference to `_D3gtk10MainWindow10MainWindow7__ClassZ'
/home/koz/Documents/Programming/D/gtkd/hello.d:24: undefined reference to `_D3gtk10MainWindow10MainWindow6__ctorMFAyaZC3gtk10MainWindow10MainWindow'
/home/koz/Documents/Programming/D/gtkd/hello.d:26: undefined reference to `_D3gtk5Label5Label7__ClassZ'
/home/koz/Documents/Programming/D/gtkd/hello.d:26: undefined reference to `_D3gtk5Label5Label6__ctorMFAyabZC3gtk5Label5Label'
/home/koz/Documents/Programming/D/gtkd/hello.d:28: undefined reference to `_D3gtk4Main4Main3runFZv'
/tmp/ccxejYOB.o:(.data+0x30): undefined reference to `_D3gtk10MainWindow12__ModuleInfoZ'
/tmp/ccxejYOB.o:(.data+0x38): undefined reference to `_D3gtk5Label12__ModuleInfoZ'
/tmp/ccxejYOB.o:(.data+0x40): undefined reference to `_D3gtk4Main12__ModuleInfoZ'
/tmp/ccxejYOB.o:(.data._D67TypeInfo_S3std8typecons35__T6scopedTC5cairo7Context7ContextZ6Scoped6__initZ[_D67TypeInfo_S3std8typecons35__T6scopedTC5cairo7Context7ContextZ6Scoped6__initZ]+0x58): undefined reference to `_D3std8typecons35__T6scopedTC5cairo7Context7ContextZ6Scoped6__dtorMFZv'
I have no clue what's going on here, and would appreciate all the help possible.
GtkD in the AUR is compiled using DMD. ABI compatibility between DMD and GDC binaries is not guaranteed and linking may fail as in your case. (Linking may also succeed and you get runtime problems). To troubleshoot the issue, you can try using DMD and see if that solves your issue.
Anyway, I would recommend using dub and gtk-d library from the dub registry. Dub will take care of the compilation of your source code and gtk-d's code and linking them together. And it will enable you to use any compiler easily.
If you don't want to use dub, you can also download gtk-d and build it yourself using GDC.
I am working on a project which modifies the control flow of user program. I am using llvm for this. At the end I generate a set of .s files using clang++. Then I use g++ to merge them all. I cant use the clang++ (instead of g++) as its giving a lot of errors at this stage (this is not the current problem)
For c programs (gcc and clang), things are working perfectly. But for c++ user code (g++, clang++) I am getting the following error when I execute
g++ -O3 -rdynamic *.s -o main.exe -Wa,-Iressource -lstdc++ -lm -ldl
/tmp/ccUdIbL3.o:(.ctors+0x0): undefined reference to `global constructors keyed to a'
/tmp/cch9k7on.o: In function `global constructors keyed to a':
_GLOBAL__I_a.optin:(.text.startup+0x1): undefined reference to `__cxx_global_var_init'
/tmp/ccvYrG8J.o:(.ctors+0x0): undefined reference to `global constructors keyed to a'
/tmp/cccPFs4G.o:(.ctors+0x0): undefined reference to `global constructors keyed to a'
As per my search on internet, for most of the people this error occurred because they use clang (instead of clang++).
Clang
clang --version
clang version 3.1 (branches/release_31)
Target: x86_64-unknown-linux-gnu
Thread model: posix
g++
g++ --version
g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
I have no idea of where the actual problem is. But I know that if I simply use clang++ to generate *.s files and then use g++ (without my llvm pass) it works fine. Since it llvm dont complain till the end then g++ does, I dont know where the actual error occurred. As I said earlier if the original code was "C" (by using clang and gcc) it works fine.
Any help on how to proceed or a solution to solve the problem is appreciated.
Specially what might lead to (in this context)
undefined reference to __cxx_global_var_init
global constructors keyed to a