When I compile my wxWidgets project, I get lots of errors stating things similar to:
undefined reference to _imp___ZN16wxEventHashTableD1EV
There are more than 50 of these, and it just started happening when I tried to statically link wxwidgets to the exe. I am using wxPack under windows. These errors did not show up when I was dynamically linking wxWidgets. Does anyone know what's going on here?
The imp* prefix means you are still pointing the linker to import libraries that go with the dynamic wxWidgets build. (.dll files located in lib/gcc_dll/*)
Make sure you built wxWidgets statically as well and then point the linker to the right location. The correct files should be under: lib/gcc_lib/*
Related
I have inherited a code project that contains several individual libraries of code that compile separately and then are linked in the compiled tools. It's supposed to be a Chinese menu of what each tool wants. This all written on Linux, in C++, with Qt. There are several issues with the current design, but I'm learning to deal.
This latest issue has me really dumbfounded. The main library is the Utilities. It contains a handful of classes and it compiles into a .a library file. Another library is our DatabaseInterfaces. It has class files that refer to header files from Utilities (they are all shared) but the CPP files are not included in DatabaseInterfaces. DatabaseInterfaces also compiles into a .a library. Finally, we have a CMDPrompt tool that imports both the Utilities.a and DatabaseInterfaces.a libraries. CMDPrompt does not compile. Instead, I get several errors indicating that I have an undefined reference for one of the objects in Utilities.
After several different attempts to fix this, I finally directly included the CPP file in the CMDPrompt.pro. It worked or at least it is now finding new undefined references for other classes in Utilities. This confirms to me that somehow the projects are not linking correctly. I would have expected that because the Utilities library is linked in I would have gotten all of the H/CPP goodness with it. I suspect the problem is that the DatabaseInterfaces library is compiling against the H files only and needs the same Utilities.a library. I tried adding that LIB into the DatabaseInterfaces.pro, but it didn't have any effect.
I am not a C++ programmer by training and while I believe I understand the main points of the linking process, I am obviously missing something. Here are my questions. Given the relationship between the different libraries, how should the linker work? Why is the DatabaseInterfaces.a compiling at all with just the H files? What is the best way to resolve this issue?
You need to link the libraries in the right order - it sounds like Utilities.a needs to be linked last. I don't know how you do that in Qt but that's what you need to achieve.
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.
Im helping on a c++ application. The application is very large and is spread out between different sub directories. It uses a script to auto generate qt .pro files for each project directory and uses qmake to then generate make files. Currently the libraries are being compiled in alphabetical order.. which is obviously causing linking errors when a library its trying to link isn't built yet.. Is there some kind of g++ flag i can set so it wont error out if a library its trying to link hasn't been built yet? or a way to make it build dependencies first through the qt .pro file?
NOTE:
This script works fine on ubuntu 10.10 because the statements to build the shared libraries didnt require that i use -l(libraryname) to link to my other libraries but ubuntu 11.10 does so it was giving me undefined reference errors when compiling on 11.10.
Have you looked into using Qt Creator as a build environment and IDE? I've personally never used it for development on Ubuntu, but I have used it on Windows with g++, and it works great there. And it appears its already available as a package in the repository.
Some of the advantages you get by using it are:
Qt Creator will (generally) manage the .pro files for you. (If you're like me, you can still add lots of extra stuff here, but it will automatically add .cpp, .h, and .ui files as they are added to the project.)
You can set up inter-project dependencies that will build projects in whatever order they need to link.
You can use its integration with gdb to step through and debug code, as well as jump to the code.
You get autocomplete on Qt signals and slots, as well as inline syntax highlighting and some error checking.
If you're doing GUIs, you can use the integrated designer to visually layout and design your forms.
Referring back to your actual question, I don't think it's possible for a flag to tell gcc to not error when a link fails simply because there is no way for the linker to lazily link libraries. If its linking to static libraries (.a), then it needs to be able to actually copy the implementation of that code into the executable/library. If its dynamically linking (.so), it still needs to verify that the required functions actually exist in the library. If it can't link it during the linkage step, when can it link?
As a bit of an afterthought, if there are cyclic dependencies in your compile process (A depends on B, B on C, and C on A), then you might need to have a fake version of a library get built first, which only has empty stubs for the implementation of each function, and the full definition for each class or object. Then, build everything else while linking to that, and at the end, build the real version of the fake library, and link it to all the other versions that were already linked. I think this would only work on dynamic linking, though.
You could use a subdirs project to have control over the build order (no matter whether the other dev wants it or not :) ).
E.g.
build_all.pro
TEMPLATE=subdirs
CONFIG+=ordered
SUBDIRS=lib2/lib2.pro lib1/lib1.pro app/app.pro
The lib1.pro, lib2.pro, ... are your generated pro files.
Then run qmake once for the build_all.pro and also run make in that directory. This will build lib2 before lib1 and then app.
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...
Good afternoon all,
I'm trying to develop my first Qt application. I'm getting many errors like the following if I try to link in static libraries with my own code:
H:/NetBeansProjects/CommonLib/aes.cpp:607: undefined reference to `__gxx_personality_sj0'
H:/NetBeansProjects/CommonLib/aes.cpp:607: undefined reference to `_Unwind_SjLj_Register'
H:/NetBeansProjects/CommonLib/aes.cpp:615: undefined reference to `_Unwind_SjLj_Resume'
My code compiles and works when not used with Qt.
The Qt program compiled and worked before I tried to link my libraries.
Google-ing it shows it may be a mismatch between compilers used to build the two sets of code. I set the Netbeans environment to use the same tool chain to build both with no
change.
I'm using Windows, NetBeans 6.9.1, and the latest Qt. I've set the compiler to use
the Qt supplied mingw compiler.
Any suggestions?
Found the solution!
It was linking in libraries from previous versions of my projects.
I installed a new version of Mingw compiler with Qt to fix an issue. I set up the new compiler as a toolchain with a different name in Netbeans.
I did a clean and build on the referenced projects using the new tool chain. Netbeans stored the compiled library in a directory named from the tool chain. It left the old version of the library in another directory named for the original tool chain.
When you add a project reference to a library Netbeans imports the path to the library. If you change the tool chain (and therefore change the path to the library) other projects still point to the old code. You have to remove the project references and re-add them.