I tried to compile a very basic example found on the boost.asio example but I'm getting linker error's. This is the complete command line I'm using:
mingw32-c++.exe -L..\..\Important\docs\c++\boost\boost_1_48_0\stage\lib -L..\..\Important\docs\c++\boost\boost_1_48_0\stage\lib -o bin\Debug\CPP_WITHOUT_FEAR_1st_APP.exe obj\Debug\main.o obj\Debug\prog_2.o obj\Debug\timer.o obj\Debug\convert.o -lwsock32 ..\..\Important\docs\c++\boost\boost_1_48_0\stage\lib\libboost_system-mgw45-mt-1_48.a
The Errors I'm getting:
..\..\Important\docs\c++\boost\boost_1_48_0\stage\lib\libboost_system-mgw45-mt-1_48.a(error_code.o):error_code.cpp:(.text+0x148): undefined reference to `_Unwind_Resume'
..\..\Important\docs\c++\boost\boost_1_48_0\stage\lib\libboost_system-mgw45-mt-1_48.a(error_code.o):error_code.cpp:(.text+0x16c4): undefined reference to `_Unwind_Resume'
..\..\Important\docs\c++\boost\boost_1_48_0\stage\lib\libboost_system-mgw45-mt-1_48.a(error_code.o):error_code.cpp:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
Tried to figure out what's wrong but I was unable to find the answer any where.
Thanks,
Sree
Are you trying to link object files compiled in gcc with your program compiled in g++ ?
`undefined reference to `__gxx_personality_v0'`
is normally related to specifying gcc as the compiler when you meant to specify g++
If this isn't the case are you trying to link object files compiled with SJLJ (setjmp/longjmp) using a DW2 (Dwarf-2) compiler or vice versa ?
E.g. Were your program's object files compiled by mingw (version 3.4.5 is SJLJ) and boost compiled by gcc (version 4.4+ is DW2) ?
If this was the case, then ensure that your compiler and the libraries you are linking to were compiled with the same compiler, that has either SJLJ exception handling or DW2 exception handling.
The minGW 4.40 beta on their website has DW2 by default now, and assuming that boost was compiled with DW2, that should then compile and link cleanly.
As for what SJLJ and DW2 are they are methods of exception handling. SJLJ uses setjmp and longjump, whilst DW2 uses DWARF-2 (or DWARF-3) debugging information. SJLJ is slower but DW2 requires more space, leading to large binaries.
For more information about exception handling see here
For how DW2 works see here
Related
I'm having an odd linking problem with Boost (version 1.58). I'm building with g++ 4.8 on Ubuntu 15.10.
I get the following error:
undefined reference to
'boost::program_options::options_description::options_description(std::string
const&, unsigned int, unsigned int)' collect2: error: ld returned 1
exit status
What's strange is that all other symbols from lboost_program_options are found; options_description is the only undefined reference. If I comment out uses of options_description but keep uses of positional_options_description (which I'm also using) then the whole program compiles and links flawlessly. I am linking with -lboost_program_options, and if I remove this then as expected there are 8 missing boost::options_description symbols.
For a long time linking has worked correctly. Without any build system changes that I'm aware of it suddenly broke. The only systems level change was an upgrade to Ubuntu 15.10, which I don't think should have affected anything.
Any thoughts or suggestions appreciated.
Update: After lots of fiddling I got this working again, although I'm not sure what did it. I'm still interested in any answers to what could cause this type of behavior though.
Check that the ABI is compatible (you're using the same compiler version and flags used when compiling the boost libraries).
On Ubuntu, this means using stock GCC with libstdc++.
If you can't, compile your own Boost System and Boost Program Options binaries using your preferred flags.
Similar things prevent code samples from linking on http://coliru.stacked-crooked.com if your compiler is not the same as used when compiling boost there.
I had a similar problem after upgrading to Ubuntu 15.10 with a different symbol missing in a lib belonging to boost::program_options.
It helped to simply clean up the whole project by throwing away all object files etc. and recompiling it from scratch.
When I try to compile a random project in Code:Blocks, the Cygwin Compiler throws an undefined reference error about own library files:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(_cygwin_crt0_common.o):_cygwin_crt0_common.cc:(.data+0x0):
undefined reference to `___real__Znwj'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(_cygwin_crt0_common.o):_cygwin_crt0_common.cc:(.data+0x8):
undefined reference to `___real__ZdlPv'
I am linking the netlink library as well as the WS2_32.lib
Is that a compiler issue?
Other hint, it comes from _cygwin_crt0_common.cc. So there is obviously central something missing. You are using Cygwin version of gcc, right? Have your tried -lcygwin? You could also try -mno-cygwin.
My advice is normally to use vanilla MinGW, creates clean windows binaries (at the loss of POSIX features)..
I have a static library that has been compiled with gcc 3.4.3 .I would like to use this in code that will now be compiled with gcc-4.
I've read vaguely that gcc-3 and gcc-4 binaries are not compatible and that the library will need to be recompiled , but just want confirmation on this.
Isn't there anyway a gcc-3 library can be used with gcc-4 ?
Getting someone else in the organization, or at a vendor, to update their library to gcc 4 is not always an option, especially if they've abandoned it.
If C++: assuming that are able to link, at runtime you can blow up in C++ standard library template code that uses streams, as symbols generated by g++ 4 are resolved against definitions generated by g++ 3.
You might see this warning when linking:
/usr/bin/ld: warning: libstdc++.so.5, needed by (legacy static lib), may conflict with libstdc++.so.6
Here's an example you can get into: base class destructor ~basic_stringbuf() (actually a template) can be defined in your module compiled under g++ 3, which mistakenly gets called by the destructor ~basic_ostringstream() in libstdc++so.6, which is invoked by the g++ 4 compiled module. Ka-Boom.
I tried compat-libstdc++-33 but had no luck with that.
That said, I still link 32-bit gcc 3 era C libraries into my gcc 4.1.2 C++ programs.
I am trying to install the mysql++ in Code::Blocks, but When I try to run the example code I get this error:
undefined reference to __imp___ZN7mysqlpp10ConnectionC1Eb
What I am doing wrong?
You must build MySQL++ with the exact same compiler and compiler options as you're using to build your program. What you're seeing is a name mangling and/or ABI mismatch due to mixing compilers and/or build options. This can be anything from a drastic error like trying to use a Visual C++ DLL with MinGW, to something more subtle like trying to use a MinGW DLL built with g++ 3.4.5 in a program you're building with MinGW g++ 4.4.
Unlike C, C++ doesn't try to preserve binary compatibility between greatly different compilers.
You probably have a linker issue. It could well be that a DLL you need isn't present, or mysql++ was compiled but not correctly linked.
I've been trying to move a project over from Xcode to Linux (Ubuntu x86 for now, but hopefully the statically-linked executable will run on an x86 CentOS machine? I hope I hope?). I have the whole project compiling but it fails at the linking stage-- it's giving me undefined references for all functions defined by IPP. This is probably something really small and silly but I've been beating my head over this for a couple days now and I can't get it to work.
Here's the compile statement (I also have a makefile that's generating the same errors):
g++ -static
/opt/intel/ipp/6.0.1.071/ia32/lib/libippiemerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippimerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippsemerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippsmerged.a
/opt/intel/ipp/6.0.1.071/ia32/lib/libippcore.a
-pthread -I /opt/intel/ipp/6.0.1.071/ia32/include
-I tools/include -o main main.cpp pick_peak.cpp
get_starting_segments.cpp
get_segment_timing_differences.cpp
recast_and_normalize_wave_file.cpp
rhythm_score.cpp pitch_score.cpp
pitch_curve.cpp
tools/source/LocalBuffer.cpp
tools/source/wave.cpp distance.cpp
...and here is the beginning of the long list of linker errors:
./main.o: In function `main':
main.cpp:(.text+0x13f): undefined reference to `ippsMalloc_16s'
main.cpp:(.text+0x166): undefined reference to `ippsMalloc_32f'
main.cpp:(.text+0x213): undefined reference to `ippsMalloc_16s'
Any ideas? FWIW, these are the IPP dependencies in my Xcode project that builds, links, and runs without a problem: "-lippiemerged",
"-lippimerged",
"-lippsemerged",
"-lippsmerged",
"-lippcore",
Thanks!
Your linking problem is likely due to the fact that your link line is completely backwards: archive libraries should follow source and object files on command line, not precede them. To understand why the order matters, read this.
Also note that on Linux statically linked executables are significantly less portable than dynamically linked ones. In general, if you link system libraries dynamically on an older Linux system, it will work on all newer systems (I use ancient RedHat 6.2, and I haven't seen a system on which my executable will not run). This is not true for completely static executables; they may crash in all kinds of "interesting" ways when moved to a system with a different libc from the one against which they were linked.
I had problems with linking code with the v 6 of the ipp; using the v11 version of the compiler (with the included updates to the ipp) mysteriously fixed them. Granted, that was with a windows platform, but I was getting 8u versions of functions to compile and no 32f versions, despite both being listed as valid in the documentation.