Code::Blocks Forums
User forums => Help => Topic started by: xnhcoder on January 01, 2006, 09:16:45 pm
-
I've noticed that many wxWidgets users (including me) when building wxWidgets apps have run into linker errors such as the following:
E:\wxWidgets-2.6.2\build-debug\lib/libwx_mswd-2.6.a(monolib_window.o)(.text+0x9fc4):../src/msw/window.cpp:4620: undefined reference to `_TrackMouseEvent@4'
E:\wxWidgets-2.6.2\build-debug\lib/libwx_mswd-2.6.a(monolib_app.o)(.text+0x5e9):../src/msw/app.cpp:300: undefined reference to `InitCommonControls@0'
The most common response to the users' pleas for help suggests checking that the libraries and paths are specified correctly. This is certainly good advice, but I've discovered that the order that the libraries are called is also crucial to a successful build. Specifically, the wxWidgets libraries must be called before the MSWindows libraries.
Notice the order in which the wxWidgets and MSWindows libraries are called in the following excerpts from the build logs from a successful and a failed build of the wxWidgets "minimal" sample. In the successful build, the wxWidgets libraries are specified before the MSWindows libraries (i.e., the linker command line flags -lwx_mswd-2.6 and -lwx_mswd_gl-2.6 come before the flags -lrpcrt4 -loleaut32 -lole32 -luuid, etc.).
Successful build --
windres.exe -i minimal.rc -J rc -o .objs\minimal.res -O coff -IE:\mingw\bin -IE:\wxWidgets-2.6.2\include
mingw32-g++.exe -Wall -g -O0 -mthreads -D__WXDEBUG__ -D__WXMSW__ -DNO_GCC_PRAGMA -DWX_PRECOMP -D_IODBC_ -IE:\msys\1.0\local\include -IE:\mingw\include -IE:\wxWidgets-2.6.2\build-debug -IE:\wxWidgets-2.6.2\build-debug\lib\wx\include\msw-ansi-debug-static-2.6 -IE:\wxWidgets-2.6.2\include -c minimal.cpp -o .objs\minimal.o
mingw32-g++.exe -LE:\msys\1.0\local\lib -LE:\mingw\lib -LE:\wxWidgets-2.6.2\build-debug\lib -o minimal.exe .objs\minimal.o .objs\minimal.res -lstdc++ -lmingw32 -mthreads -lwx_mswd-2.6 -lwx_mswd_gl-2.6 -lwxtiffd-2.6 -lwxjpegd-2.6 -lwxpngd-2.6 -lwxzlibd-2.6 -lwxregexd-2.6 -lwxexpatd-2.6 -lrpcrt4 -loleaut32 -lole32 -luuid -lgdi32 -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32 -lwsock32 -lwinmm -lwinspool E:\msys\1.0\local\lib\libglui.a E:\msys\1.0\local\lib\libglut32.a E:\msys\1.0\local\lib\libglut.a E:\msys\1.0\local\lib\libglu32.a E:\mingw\lib\libopengl32.a -mwindows
Process terminated with status 0 (1 minutes, 26 seconds)
0 errors, 0 warnings
Failed build --
windres.exe -i minimal.rc -J rc -o .objs\minimal.res -O coff -IE:\mingw\bin -IE:\wxWidgets-2.6.2\include
mingw32-g++.exe -Wall -g -O0 -mthreads -D__WXDEBUG__ -D__WXMSW__ -DNO_GCC_PRAGMA -DWX_PRECOMP -D_IODBC_ -IE:\msys\1.0\local\include -IE:\mingw\include -IE:\wxWidgets-2.6.2\build-debug -IE:\wxWidgets-2.6.2\build-debug\lib\wx\include\msw-ansi-debug-static-2.6 -IE:\wxWidgets-2.6.2\include -c minimal.cpp -o .objs\minimal.o
mingw32-g++.exe -LE:\msys\1.0\local\lib -LE:\mingw\lib -LE:\wxWidgets-2.6.2\build-debug\lib -o minimal.exe .objs\minimal.o .objs\minimal.res -lstdc++ -lmingw32 -mthreads -lwxtiffd-2.6 -lwxjpegd-2.6 -lwxpngd-2.6 -lwxzlibd-2.6 -lwxregexd-2.6 -lwxexpatd-2.6 -lrpcrt4 -loleaut32 -lole32 -luuid -lgdi32 -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32 -lwsock32 -lwinmm -lwinspool -lwx_mswd-2.6 -lwx_mswd_gl-2.6 E:\msys\1.0\local\lib\libglui.a E:\msys\1.0\local\lib\libglut32.a E:\msys\1.0\local\lib\libglut.a E:\msys\1.0\local\lib\libglu32.a E:\mingw\lib\libopengl32.a -mwindows
E:\wxWidgets-2.6.2\build-debug\lib/libwx_mswd-2.6.a(monolib_window.o)(.text+0x9fc4):../src/msw/window.cpp:4620: undefined reference to `_TrackMouseEvent@4'
E:\wxWidgets-2.6.2\build-debug\lib/libwx_mswd-2.6.a(monolib_app.o)(.text+0x5e9):../src/msw/app.cpp:300: undefined reference to `InitCommonControls@0'
E:\wxWidgets-2.6.2\build-debug\lib/libwx_mswd-2.6.a(monolib_app.o)(.text$_Z15wxOleInitializev[wxOleInitialize()]+0xe):../include/wx/intl.h:558: undefined reference to `OleInitialize@4'
E:\wxWidgets-2.6.2\build-debug\lib/libwx_mswd-2.6.a(monolib_app.o)(.text$_Z17wxOleUninitializev[wxOleUninitialize()]+0x7):../include/wx/log.h:376: undefined reference to `OleUninitialize@0'
[***]
E:\wxWidgets-2.6.2\build-debug\lib/libwx_mswd-2.6.a(monolib_dataobj.o)(.data+0xc):../include/wx/msw/ole/oleutils.h:75: undefined reference to `IID_IDataObject'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 58 seconds)
41 errors, 0 warnings
Hope this information is useful.
:lol: Happy New Year!! :lol:
-
The most common response to the users' pleas for help suggests checking that the libraries and paths are specified correctly. This is certainly good advice, but I've discovered that the order that the libraries are called is also crucial to a successful build. Specifically, the wxWidgets libraries must be called before the MSWindows libraries.
Hmmm, the order of the libraries is important, but I have built (compiled&linked) wxWidgets applications where the M$ libraries did come before the wxWidgets ones. Anyway, I was using M$ Toolkit 2003 and this could be the reason, but I am not sure.
Michael
-
noticed too that the gcc linker isn't smart as the M$ companion.
rule of thumb for gcc :
1. private libraries,
2. wxwidgets libraries (order as shown in wx-samples !!!)
3. windows libs
4. link and pray
-
rule of thumb for gcc :
1. private libraries,
2. wxwidgets libraries (order as shown in wx-samples !!!)
3. windows libs
4. link and pray
That's is interesting. Especially for developers using both GNU and M$ (as myself :)).
Ehm...you say pray :D?
Michael
-
That's is interesting. Especially for developers using both GNU and M$ (as myself :)).
didn't you ever fall into this pit ?
-
didn't you ever fall into this pit ?
Hmmm. I was having some linking troubles with an wxWidgets application that did compile with M$, but not with GNU. But I thought it was because of my little experience with GNU. Now, I can check if it is an order problem :).
Anyway, and not to go too off-topic :), GNU seems to me more strict than M$. Experienced this when I have ported for the first time a M$ project that made use of templates to GNU.
Michael
-
Hmmm, the order of the libraries is important, but I have built (compiled&linked) wxWidgets applications where the M$ libraries did come before the wxWidgets ones.
Well, there I go again. Saying the wxWidgets libraries "must" come before the Windows libraries is probably an overstatement. My intent was just to show an example where order is crucial and to give users another line of investigation when the libraries themselves and their locations seem perfectly fine.
-
wxWidgets libraries "must" come before the Windows libraries
The rule for gcc is that libraries on the command line must come before-be to the left of-any libraries they depend on. They must be listed in reverse dependency order.
-
rule of thumb for gcc :
[...]
2. wxwidgets libraries (order as shown in wx-samples !!!)
[...]
Yes, examining the "minimal" makefile and my experience with the importance of order when building GLUI-GLUT-OpenGL apps is what prompted me to try adjusting the order of the libraries.
-
The rule for gcc is that libraries on the command line must come before-be to the left of-any libraries they depend on. They must be listed in reverse dependency order.
But other than by being mentioned in a library's documentation or by trial-and-error, how can one determine a library's dependency?
-
Makes sense, but other than by being mentioned in a library's documentation or by trial-and-error, how can one determine a library's dependency?
You get a linker error :)
Unresolved external declaration....
so just search for that symbol in all the project dlls with a hex editor. Ultraedit makes this simple to do (can search for strings in binary dlls).