Problem:
When I try to open some applications I get errors from the linker like this:
/usr/lib/x86_64-linux-gnu/libpoppler-qt5.so.1: undefined symbol: _ZN6QDebugD1Ev
Some applications affected are
texstudio shows
/usr/lib/x86_64-linux-gnu/libpoppler-qt5.so.1: undefined symbol: _ZN6QDebugD1Ev
IPython's qtconsole shows
/usr/lib/python3.5/site-packages/PyQt5/QtCore.so: undefined symbol: _ZNK12QStorageInfo11displayNameEv
konsole (KDE's terminal emulator - I'm using Unity though) shows
/usr/lib/x86_64-linux-gnu/libKF5ItemViews.so.5: undefined symbol: ...
granatier (a KDE game), KSysguard and KAddressbook also show errors in KF5 libraries
VLC seems to be affected too since it says there is something wrong with Qt 4 (see below). However it doesn't ecplicitely say it's a linking problem.
It seems to be a problem with dynamic linking and I my guess would be that the problem is in the libraries
Qt
all of this errors seem to come from Qt linked libraries ("Qt" appears in most filenames and most symbol names). AFAIK KDE ist baed on Qt, which would explain why all KDE applications fail.
It seems to affect both Qt 4 and 5
I also had a similar problem with ssl but it went away eventually (maybe an update).
I'm using ld 2.25
Why I'm asking here
I realize that my Question is not about programming. The help center states that
Questions about general computing hardware and software are off-topic for Stack Overflow unless they directly involve tools used primarily for programming.
This seems to be a problem with the linker / the dynamic libraries so I would say it kind of involves programming tools.
If you disagree please spare the downvotes and write a comment explaining you POV.
Okay, this kind of problems happen a lot if you switch to 'unstable'.
What you need to do is downgrade all of your packages back to 'stable'. Modifying sources.list wouldn't be enough, you also need to change priorities.
Look this thread: https://unix.stackexchange.com/questions/117122/how-to-get-back-from-testing-to-stable-kernel-downgrade
Ok, so it seems the source of the problem was that I had Qt linked libraries like libQt5Core.so.5 in /usr/local/lib. When I remove them everything worked again.
I've read that the package manager doesn't put any libraries there, so it was probably me who did a dumb mistake. It looks like it wasn't a programming problem at all in the end.
Related
I am currently working on a masters project and I am desperately trying to compile some C++ code on my mac (macOS High Sierra 10.13.3 using Xcode) so I can develop the program at home. The Program is a set of files used for performing integrals on a bunch of different data... it uses headers from the boost library and also alglib. This all works fine on Windows machines running visual studios.
The issue I have is that when I include boost (which was installed via homebrew to usr/local/) into the search paths in the project build settings I get all sorts of semantic and linker issues.
I have searched this for a while and tried to implement a few potential fixes. I have tried:
Compiling with different C++ dialects and and standard libraries (libc++ and libstdc++).
Uninstalling/reinstalling boost.
Removing suggested header files and libraries from 'usr/local' suggested by brew doctor.
and implementing all sorts of other random permutations of settings that I felt could be issued.
The number of errors and warnings may change using different build settings however semantic issues persist and I am running out of ideas for how to proceed. It is really important I get this working and any insight would be appreciated.
From my reading about and attempting to troubleshoot I get the idea that it is some kind of linking issue between the boost library and the standard c++ libraries, but I have little experience with semantic issues as in the past I have been lucky enough that things just worked! Perhaps my MacBook may just have too much going on and needs some housecleaning to stop confusing the compiler, but regardless if anyone can help me fix this issue I would be eternally grateful!
I understand I haven't provided much detail here but if any information would be useful I'm happy to send screenshots.
link to errors image
In C++03 ifstream did not have a constructor that accepts std::string.
Such a constructor was added in C++11. The same holds for std::stod: it exists since C++11.
So you have to compile with -std=c++11 option.
I have edited out a lot of my original situation to try keep things simple; it can be seen in the revisions.
Basically I have been following a tutorial in which a game engine is being created.
Most of the code has been separated into its own CodeLite project and successfully compiled into a static library (libbengine.a using mingw32 via TDM-GCC-32).
(For the record, the code compiled fine before separation)
Back in the main game code (main.cpp, etc) the compiler knows the relevant include and lib directories and compilation can at least locate the necessary headers and lib.
However, I get this error: undefined reference to '__glewCreateProgram'
Any ideas as to what is getting lost in translation (so-to-speak)?
I have been reading around all over the place; researching compilation, static libraries, ar.exe, but am having no luck (I am still looking).
If you want any more pertinent information, I will happily provide it; for now I shan't clog up the post any further.
Cheers
To give a basic idea of the error in CodeLite:
Main project linker settings:
bengine project linker settings (compiled as static lib.a):
It seems the problem was solely with linking order. As can be seen in the second image in my question (Main linker setting) - "Bengine" should have been at the top of the list, not the bottom.
This may be mingw32 specific; I am not sure.
Well, after all those hours, I feel somewhat foolish...
At least I have learned some things along the way.
this question has gone back and forth a bit as I have learnt some things about g++ about unix systems (sorry if I messed anyone about).
For a project I am currently trying to finish I would like to get twitcurl running with Xcode and OpenFrameworks. If anyone has managed to do this please share with me this arcane feat.
Below is some of the things I am stuck on:
Regurgitating some of the instructions from their wiki it says to
download the libraries source
build twitcurl library using visual C++ or make (their is also cmake in their).
Include twitcurl.h and curl headers in your twitter application and link to twitcurl.lib and libcurl.lib/libcurl.dll.
This seems simple enough but when I make the library, there is no twitcurl.lib. A different file libtwit.a is produced, which I assume must be what OSX needs (as installing puts it in usr/local/ along with the headers). However then if I try to include the twitcurl.h in a header and make a twitCurl object I then get more undefined symbols
Undefined symbols for architecture i386:
"twitCurl::~twitCurl()", referenced from:
testApp::setup() in testApp.o
"twitCurl::twitCurl()", referenced from:
testApp::setup() in testApp.o
ld: symbol(s) not found for architecture i386
I now am assuming twitcurl makes for a 64bit (I have tried adding CFLAGS=-m32, but it fails), and to my knowledge Openframeworks is only 32 bit currently. This means twitcurl may not be an option for me, but again, if anyone knows how please let me know!
Thanks in advance.
You'd probably do well to recompile twitcurl, last I looked (3 months ago), it was compiled with VC6, which has its own way of mangling C++ symbols, so the lib won't link correctly for g++.
you could then just import it directly as well and then not need to worry about linking to the libs, however it would be a good idea to test in a small demo app, before integrating into an already build system, that way you know if the error is on your side or somewhere else.
Also, when it comes to this type of problem, the exact compiler errors are more helpful than just describing the problem.
The error message you've posted is the linker's longwinded way of telling you that its looking for a definition of the curl_easy_setopt function, which is part of libcurl. Adding -lcurl to your g++ line should fix this (by telling the linker to link in libcurl).
However, twitcurl comes with a Makefile, which already does this. In addition, if you are trying to build a shared library there, you're doing it wrong...
Maybe you can try ofxTwitter, an openFrameworks addon for twitter, to get your twitter functionality. get it here: http://forum.openframeworks.cc/index.php/topic,2750.0.html
I am currently building a rather large application, using cmake to generate cross platform build scripts. During this process of putting together the cmake build scripts, I have discovered the pain of gcc link line ordering.
The basic issues is that including static libraries in the wrong order leads to unused library symbols being thrown away that then cannot be found by subsequent dependent libraries.
Thus, I am in the situation where cmake generates a visual studios build system that compiles just fine, but the unix makefiles throw all kinds of "undefined symbol" errors. I have figured out a work around for this - in the add_executable command, I am including the static libraries twice.
My hope is that there is a more standard/better way to deal with this issue. Being that I am not the only developer, and that the majority of regular development is done in windows, I really want a link-order agnostic CMake script. The windows developers just don't deal with this link order issue. On top of that, figuring out the correct order would be very difficult - I do not have that information readily available and there are a lot of static libraries (70 or so).
After searching the internet, I did learn about the -static and -dynamic flags, but getting CMake to include them is non-obvious and gcc complains about not being able to find the dynamic libraries.
Anyway, I welcome suggestions on how to do the right thing.
Did you try disabling the strip? Maybe with something like cmake -DCMAKE_STRIP=/bin/true ..? Maybe that will stop the symbols being thrown out.
I think this is less of a CMake issue, and more of a GCC behavior. This question/answer should help out a bit:
Linker order in GCC
You will have to bite the bullet and modify your CMakeLists.txt files to link properly on Linux. Since the Windows developers don't care, you shouldn't disturb them.
Best,
-dan
While developing a SWIG wrapped C++ library for Ruby, we came across an unexplained crash during exception handling inside the C++ code.
I'm not sure of the specific circumstances to recreate the issue, but it happened first during a call to std::uncaught_exception, then after a some code changes, moved to __cxa_allocate_exception during exception construction. Neither GDB nor valgrind provided any insight into the cause of the crash.
I've found several references to similar problems, including:
http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception
http://forums.fifengine.de/index.php?topic=30.0
http://code.google.com/p/osgswig/issues/detail?id=17
https://bugs.launchpad.net/ubuntu/+source/libavg/+bug/241808
The overriding theme seems to be a combination of circumstances:
A C application is linked to more than one C++ library
More than one version of libstdc++ was used during compilation
Generally the second version of C++ used comes from a binary-only implementation of libGL
The problem does not occur when linking your library with a C++ application, only with a C application
The "solution" is to explicitly link your library with libstdc++ and possibly also with libGL, forcing the order of linking.
After trying many combinations with my code, the only solution that I found that works is the LD_PRELOAD="libGL.so libstdc++.so.6" ruby scriptname option. That is, none of the compile-time linking solutions made any difference.
My understanding of the issue is that the C++ runtime is not being properly initialized. By forcing the order of linking you bootstrap the initialization process and it works. The problem occurs only with C applications calling C++ libraries because the C application is not itself linking to libstdc++ and is not initializing the C++ runtime. Because using SWIG (or boost::python) is a common way of calling a C++ library from a C application, that is why SWIG often comes up when researching the problem.
Is anyone out there able to give more insight into this problem? Is there an actual solution or do only workarounds exist?
Thanks.
Following Michael Dorgan's suggestion, I'm copying my comment into an answer:
Found the real cause of the problem. Hopefully this will help someone else encountering this bug. You probably have some static data somewhere that is not being properly initialized. We did, and the solution was in boost-log for our code base. https://sourceforge.net/projects/boost-log/forums/forum/710022/topic/3706109. The real problem is the delay loaded library (plus statics), not the potentially multiple versions of C++ from different libraries. For more info: http://parashift.com/c++-faq-lite/ctors.html#faq-10.13
Since encountering this problem and its solution, I've learned that it's important to understand how statics are shared or not shared between your statically and dynamically linked libraries. On Windows this requires explicitly exporting the symbols for the shared statics (including things like singletons meant to be accessed across different libraries). The behavior is subtly different between each of the major platforms.
I recently ran into this problem as well. My process creates a shared object module that is used as a python C++ extension. A recent OS upgrade from RHEL 6.4 to 6.5 exposed the problem.
Following the tips here, I merely added -lstdc++ to my link switches and that solved the problem.
Having the same problem using SWIG for Python with a cpp library (Clipper), I found that using LD_PRELOAD as you suggested works for me too.
As another workaround which doesn't require LD_PRELOAD, I found that I can also link the libstdc++ into the .so library file of my module, e.g.
ld -shared /usr/lib/i386-linux-gnu/libstdc++.so.6 module.o module_wrap.o -o _module.so
I can then import it in python without any further options.
I realise that #lefticus accepted the answer relating to what I guess amounts to undefined static init order; however, I had a very similar problem, this time with boost::python.
I tried my damndest to find any static initilisation issues and couldn't - to the point that I refactored a major chunk of our codebase; and when that didn't work ended up removing exceptions altogether.
However, some more crept in and we started getting these segfaults again.
After some more investigation I came across this link which talks about custom allocators.
We do indeed use tcmalloc ourselves; and after I removed it from our library which is exported to boost::python we had no more issues!
So just an FYI to anyone who stumbles across this thread - if #lefticus's answer doesn't work, check if you're using a different allocator to that which python uses.