[2.9.1] Compiling wxWidgets-2.9.1 with MinGW [Error 1] Topic is solved
-
- Earned a small fee
- Posts: 23
- Joined: Tue Jul 20, 2010 1:55 am
[2.9.1] Compiling wxWidgets-2.9.1 with MinGW [Error 1]
I've this problem:
I've compiled with these build options:
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1 USE_ODBC=1 UNICODE=1 BUILD=debug
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1 USE_ODBC=1 UNICODE=1 BUILD=release
I've always compiled in this way with success...
Why wxWidgets 2.9.1 gets this error?
I've compiled with these build options:
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1 USE_ODBC=1 UNICODE=1 BUILD=debug
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1 USE_ODBC=1 UNICODE=1 BUILD=release
I've always compiled in this way with success...
Why wxWidgets 2.9.1 gets this error?
Did you do a clean build of everything you are building, starting with the library? Are you sure you are not trying to create the debug dll using [some] release objects? What does "_custom" come from?
Those errors signal that you have some objects (i.e. the one containing wxVector) built with asserts enabled (wxDEBUG_LEVEL>0) but the assert code is actually missing. That is not possible by default in debug build as wxDEBUG_LEVEL is by default set to 1.
You should probably figure it out where wxDEBUG_LEVEL is wrongly defined in your setup (the corresponding option for the makefile is 'DEBUG_FLAG'), or come back with some more details.
p.s. 'USE_ODBC' is not used in 2.9.x
Those errors signal that you have some objects (i.e. the one containing wxVector) built with asserts enabled (wxDEBUG_LEVEL>0) but the assert code is actually missing. That is not possible by default in debug build as wxDEBUG_LEVEL is by default set to 1.
You should probably figure it out where wxDEBUG_LEVEL is wrongly defined in your setup (the corresponding option for the makefile is 'DEBUG_FLAG'), or come back with some more details.
p.s. 'USE_ODBC' is not used in 2.9.x
I don't know why, but on Windows he custom suffix always seems to be addedcatalin wrote:What does "_custom" come from?
Otherwise I agree with catalin's diagnostic, seems like some debug objects are being linked in the release build. Try separating the builds (under unix we solve that we build dirs; not sure how on windows)
"Keyboard not detected. Press F1 to continue"
-- Windows
-- Windows
-
- Earned a small fee
- Posts: 23
- Joined: Tue Jul 20, 2010 1:55 am
Yezcatalin wrote:Did you do a clean build of everything you are building, starting with the library? Are you sure you are not trying to create the debug dll using [some] release objects?
This is the name of my output dll (from SHARED=1 option)catalin wrote:What does "_custom" come from?
This is an example of my attempt to compile a release dll
the command lines:
cd %WXWIN%\build\msw (%WXWIN% is my wxwidgets path)
SET PATH=C:\Program Files (x86)\MinGW\bin;C:\Program Files (x86)\MinGW\mingw32\bin
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1 UNICODE=1 BUILD=release CLEAN
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1 UNICODE=1 BUILD=release
and the result is:
Why?? I want to compile my 2.9.1 dll... =(((
Run your make clean command(s) and instead of 'clean' use 'build_cfg_file'. It will generate 'build.cfg' file(s) in the corresponding lib directory. Post here the contents.
By the commands you've posted you should see DEBUG_FLAG=1 for both release and debug builds (which would be correct/default). If you see something else then something is wrong somewhere.
Edit: you should probably check that the linker does look for the needed objects in the same directory where the compiler puts the newest ones.
By the commands you've posted you should see DEBUG_FLAG=1 for both release and debug builds (which would be correct/default). If you see something else then something is wrong somewhere.
Edit: you should probably check that the linker does look for the needed objects in the same directory where the compiler puts the newest ones.
-
- Earned a small fee
- Posts: 23
- Joined: Tue Jul 20, 2010 1:55 am
Here build.cfg (release):catalin wrote:Run your make clean command(s) and instead of 'clean' use 'build_cfg_file'. It will generate 'build.cfg' file(s) in the corresponding lib directory. Post here the contents.
Code: Select all
WXVER_MAJOR=2
WXVER_MINOR=9
WXVER_RELEASE=1
BUILD=release
MONOLITHIC=1
SHARED=1
UNICODE=1
WXUNIV=0
CFG=
VENDOR=custom
OFFICIAL_BUILD=0
DEBUG_FLAG=1
DEBUG_INFO=default
RUNTIME_LIBS=dynamic
MSLU=0
USE_EXCEPTIONS=1
USE_THREADS=1
USE_GUI=1
USE_HTML=1
USE_MEDIA=1
USE_OPENGL=1
USE_QA=0
COMPILER=gcc
CC=gcc
CXX=g++
CFLAGS=
CPPFLAGS=
CXXFLAGS=
LDFLAGS=
Code: Select all
WXVER_MAJOR=2
WXVER_MINOR=9
WXVER_RELEASE=1
BUILD=debug
MONOLITHIC=1
SHARED=1
UNICODE=1
WXUNIV=0
CFG=
VENDOR=custom
OFFICIAL_BUILD=0
DEBUG_FLAG=1
DEBUG_INFO=default
RUNTIME_LIBS=dynamic
MSLU=0
USE_EXCEPTIONS=1
USE_THREADS=1
USE_GUI=1
USE_HTML=1
USE_MEDIA=1
USE_OPENGL=1
USE_QA=0
COMPILER=gcc
CC=gcc
CXX=g++
CFLAGS=
CPPFLAGS=
CXXFLAGS=
LDFLAGS=
I have the same issue.
I built a few minutes ago 2.8.10 and 2.8.11 without problems and it failed building 2.9.1 for the same linker problems.
I tested with gcc 4.4.1 TDM 2 and I'm testing now with 4.5.0 TDM 1.
Edit:
It was not on the SVN, on a clean 2.8.10, 2.8.11 and 2.9.1.
Here are the results with 4.5.0 TDM1:
-> 2.9.1: failed,
-> latest svn: failed,
What is weird is that it seems the problem comes from libwxscintilla...
Edit 3:
It failed too with a gcc 3.4.5.
Edit 4:
Btw., I had no problem building Scintilla 2.1.2 with gcc 4.5.0 tdm 1.
Works like a charm.
Edit 5:
Building with MONOLITHIC=0 works.
Could it be that something is missing in your port of scintilla under windows and gcc?
It seems all is not working because of this link with "wxTheAssertHandler" which is in fact in "src/common/appbase.cpp".
I built a few minutes ago 2.8.10 and 2.8.11 without problems and it failed building 2.9.1 for the same linker problems.
I tested with gcc 4.4.1 TDM 2 and I'm testing now with 4.5.0 TDM 1.
Edit:
It was not on the SVN, on a clean 2.8.10, 2.8.11 and 2.9.1.
Here are the results with 4.5.0 TDM1:
-> 2.9.1: failed,
-> latest svn: failed,
What is weird is that it seems the problem comes from libwxscintilla...
Edit 3:
It failed too with a gcc 3.4.5.
Edit 4:
Btw., I had no problem building Scintilla 2.1.2 with gcc 4.5.0 tdm 1.
Works like a charm.
Edit 5:
Building with MONOLITHIC=0 works.
Could it be that something is missing in your port of scintilla under windows and gcc?
It seems all is not working because of this link with "wxTheAssertHandler" which is in fact in "src/common/appbase.cpp".
-
- I live to help wx-kind
- Posts: 194
- Joined: Fri Feb 17, 2006 4:16 am
- Location: Singapore
- Contact:
There are two ways. (I'm assuming release build is being built)
1) Change DEBUG_FLAG ?= 0 inside config.gcc file or issue DEBUG_FLAG=0 when enter make command in command prompt.
2) Manually edit setup.h file - uncomment line no 69 to 73 and then build.
Please note that you can build multi-lib build. Even after doing above Monolithic build throws one linker error which I could not figure out.
To read about the changes to build system read the following article.
1) Change DEBUG_FLAG ?= 0 inside config.gcc file or issue DEBUG_FLAG=0 when enter make command in command prompt.
2) Manually edit setup.h file - uncomment line no 69 to 73 and then build.
Please note that you can build multi-lib build. Even after doing above Monolithic build throws one linker error which I could not figure out.
To read about the changes to build system read the following article.
Thanks for the reply and the link
I tried adding the debug flag in the make but I finished ending with the same linker errors:
I'm trying now with the other solution(s).
And yeah you're right, the multi-lib is working
Edit:
So I tried with both your solutions, both of them failed sadly, same error as before
I tried adding the debug flag in the make but I finished ending with the same linker errors:
Code: Select all
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 DEBUG_FLAG=0 clean
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 DEBUG_FLAG=0
And yeah you're right, the multi-lib is working
Edit:
So I tried with both your solutions, both of them failed sadly, same error as before
Hi,
I have the same problems compiling with MinGW for windows and also with Visual C++ 2010 and wxWidgets-2.9.1
For me there is an error in the makefile.gcc and also in the makefile.vc
For makefile.gcc on line 183 in WXSCINTILLA_CXXFLAGS there is a define -DWXUSINGDLL, after I remove that define I could make the libraries with the command mingw32-make.exe -f makefile.gcc UNICODE=1 BUILD=release SHARED=0 and all the same linkers error disappear. Also there is a define -DWXUSINGDLL in the corresponding section of makefile.vc line 195 that makes the Microsoft compiler to complain about importing some functions in static libraries. But now I have a lot of problems with wxStyledTextCtrl. BraceMathing is broken. Line Endings is broken. Some search function are broken in that control.
I have the same problems compiling with MinGW for windows and also with Visual C++ 2010 and wxWidgets-2.9.1
For me there is an error in the makefile.gcc and also in the makefile.vc
For makefile.gcc on line 183 in WXSCINTILLA_CXXFLAGS there is a define -DWXUSINGDLL, after I remove that define I could make the libraries with the command mingw32-make.exe -f makefile.gcc UNICODE=1 BUILD=release SHARED=0 and all the same linkers error disappear. Also there is a define -DWXUSINGDLL in the corresponding section of makefile.vc line 195 that makes the Microsoft compiler to complain about importing some functions in static libraries. But now I have a lot of problems with wxStyledTextCtrl. BraceMathing is broken. Line Endings is broken. Some search function are broken in that control.
-
- Earned a small fee
- Posts: 23
- Joined: Tue Jul 20, 2010 1:55 am
Ok now is seems that you can compile in multi-lib method (monolithic=0).
Working Methods:
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1 UNICODE=1 BUILD=debug CLEAN
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1 UNICODE=1 BUILD=release CLEAN
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1 UNICODE=1 BUILD=debug
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1 UNICODE=1 BUILD=release
Working Methods:
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1 UNICODE=1 BUILD=debug CLEAN
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1 UNICODE=1 BUILD=release CLEAN
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1 UNICODE=1 BUILD=debug
mingw32-make.exe -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=0 USE_OPENGL=1 UNICODE=1 BUILD=release
Ok it seems it's possible to build MONOLITHIC=1, creadits to stahta01 from Codeblocks forum, here is how:
Steps:
1°) delete all the files in "Widgets-2.9.1\lib\gcc_dll\" (so well it's a clean),
2°) open the file "wxWidgets-2.9.1\include\wx\msw\setup.h",
3°) inside the file "setup.h", set "wxUSE_STC" to 0 (instead of 1) and save it,
4°) Use those commands to build what you need (USE_STC must be set to 0):
And it works
Steps:
1°) delete all the files in "Widgets-2.9.1\lib\gcc_dll\" (so well it's a clean),
2°) open the file "wxWidgets-2.9.1\include\wx\msw\setup.h",
3°) inside the file "setup.h", set "wxUSE_STC" to 0 (instead of 1) and save it,
4°) Use those commands to build what you need (USE_STC must be set to 0):
Code: Select all
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 USE_STC=0 USE_PROPGRID=1 BUILD=release clean
mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 USE_STC=0 USE_PROPGRID=1 BUILD=release