I've written a program which compiles and runs as expected (without problems) on my Ubuntu 12.10 distribution at home. I then transfer my program to my university server, where I was first met with an error (similar to this question)
/usr/lib/libstdc++.so.6: version 'GLIBCXX_3.4.9' not found (required by ./main)
As suggested in the thread, I then added -static-libstdc++ to the linker settings, such that I use static linking. Now I get the error
undefined symbol: _ZNSt8time_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE2idE
I haven't been able to find any information about this online, but I thought perhaps it is yet another linker problem. If anyone has some input, I would be happy to read it as I am all out of good ideas.
This is a pretty standard example of compiling against one version of the C runtime library and trying to run it against another. Statically compiling should help.
Did you add -static when building?
Related
This isn't my code, I am not a programmer but I did not expect simply compiling a provided source code would be so difficult.
Here it is, taken from Joel Yliluoma's page about "arbitrary-palette positional dithering algorithm", it was written in 2011.
This was my troubleshooting process, using MinGW:
The code didn't seem to make sense at all, so I realized it was written in an earlier version of C++, and added -std=c++98.
It couldn't find gd.h, I downloaded that from libgd's website, and directed to its directory using -I.
A bunch of gd related commands got a "undefined reference to" treatment. I tried to direct the compiler to gd.h/gd.c directory again using -l and followed by -lgd. And this is where I got stuck, as
The compiler insisted on not being able to find -lgd. I tried with different versions of libgd (especially older ones, before 2011) and sometimes it'd find what it's looking for, but then skip over them as they are incompatible.
I've also tried to compile it with another program called Dev-C++ but to no avail. Dev-C++ also gave back a "linker error". I can only assume that I messed up linking the header or library somehow, but I do not know what those terms mean frankly and just wanted a working program so I can get back to my imagery stuff. Maybe I downloaded the wrong gd.h, or I'm missing a required thing. Any help would be greatly appreciated.
Here's my current final MinGW input:
g++ -std=c++98 -Ipath\to\libgd code.cpp -Lpath\to\libgd -lgd -o executable.exe
I can assure you that path\to\libgd contains gd.h (and a bunch of other gd related stuff) and either one of these depending on which version of libgd I found: libgd.lib, libgd.dll.a, lidgb.def, libgd.rc, libgd.so.
I'm using Windows 7 64-bit.
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.
So I installed the toolchain given by raspberry which works good , I managed to compile the library used by the GUI
I have installed all dependancies for the GUI using
xapt -a armhf -m [packet]
But when the linker has to link all librairies it give me the following error and I'm stuck.
arm-linux-gnueabihf-ld: pkcs11dialogs.o: undefined reference to symbol '_Znwj##GLIBCXX_3.4'
/usr/arm-linux-gnueabihf/lib/libstdc++.so.6: error adding symbols: DSO missing from command line
Any help will be very appreciate !
Merci !
The problem is that you're compiling C++ code and not C. C++ needs a runtime support library, the native GCC library is called libstdc++ and you need to link with that.
It's very easy to do: Use the g++ (arm-linux-gnueabihf-g++ in your case) frontend program to link as well as compile., it will automatically add the C++ runtime library. Or add it manually to your linker command.
Have wasted almost full 4 days trying to compile this package. It compiles fine in OSX 10.6, but gives Undefined reference errors when I try to compile it on a linux (Kubuntu 10.04, 3.8.0.27 kernel) machine.
The error seem to be that the makefiles are ordered wrong, but AFAIK, I am the only one having trouble compiling it. So I'm trying to find what's making the difference. The software package is quite big and editing the Makefiles and moving 30-50 libraries here and there doesn't seem like a good idea.
Here's the differences I think I found so far
Compiler - gcc-4.7 (Linux) and llvm-gcc-4.2 (OSX)
Compiler flags --shared (Linux) and -dynamic -dynamiclib -undefined dynamic_lookup (OSX)
Anyone have any suggestions?
I tried using clang++ and llvm-gcc-4.7 as the compiler, but I think it still used the same linker (ld?). So I could try to specify to use llvm? How do I do that?
is --shared flag somehow different from the dynamic -dynamiclib -undefined dynamic_lookup flags in OSX?
Does the linux kernel or distribution matter? (I think they compiled it fine on a CentOS machine)
Please help.
Thanks a lot.
Compiled it with gcc 4.4 and worked flawlessly. I guess the order doesn't matter on 4.4 for the given package.
The undefined references type of errors can be caused by a symbol not being compiled in, not being linked or being linked out of order. The way to debug this is to check the linker line, the symbol that the linker complains about. The error message will probably tell you what object file has the dependency.
Now, you need to find out whether the symbol is compiled or linked, for that you will need to find if it is in any of the object files or in any of the libraries and which. You can use the nm command line tool to list the symbols that are defined in any given .o or library. If the symbol is not there, then you need to figure out what to add to the linker line and that will solve it.
If the symbol appears in one library, then identify which of the libraries depends on that symbol (from the linker error message) and the library that contains it. The former must be listed before the latter in the linker command line (assuming static linking).
As a simple hack, although I recommend against it, you can instruct the gcc linker to do multiple passes by using the --start-group and --end-group command line options. Although I really recommend that you figure out the order of dependencies, as that will also give you a better insight into your project.
I'm trying to port/build some of my code written for gcc (on linux) as a dll on windows. First I tried to build in under VC++ but there were so many errors/warnings (mainly in VC's own include files, which didn't really make much sense to me :)) so I installed MinGW distro (which includes Boost libraries). Compilation went quite smoothly, however linking failed with undefined references to functions from boost libraries. The "-t" parameter showed that the linker doesn't actually use the boost libraries for some reason (yes, the -L path is correct, the libraries are there, linker doesn't complain when I use -l).
After much googling I found out that the order is the problem, that I have to place my -l parameters after all my .o files (because of dependencies). This seemed to solve all the problems except one undefined reference to thread library. Again -t showed that this library is actually not used by the linker (not in the list) the others are (I use boost_system and boost_date_time as well). I played with the order of the parameters again but the result was the same. Any idea what am I missing?
The error is:
c:/x5/cpp/build//timed_cond.o:timed_cond.cpp:(.text$_ZN5boost6detail24basic_condition_variable7do_waitINS_11unique_lockINS_5mutexEEEEEbRT_NS0_7timeoutE[bool boost::detail::basic_condition_variable::do_wait<boost::unique_lock<boost::mutex> > (boost::unique_lock<boost::mutex>&, boost::detail::timeout)]+0x246): undefined reference to `_imp___ZN5boost11this_thread18interruptible_waitEPvNS_6detail7timeoutE'
I use same versions of Boost library (1.44.0) on both platforms
Ok, I found the answer. Looks like the problem is in boost libraries being static in MinGW-distro. Normally they are configured to be linked dynamically and that caused above issue. This answer explains it...