User forums > Help
Can't succeed to compile CB SVN against wxWidgets 2.8 under OSX 10.6.8 (solved)
eranon:
Hello,
I'm implementing an OSX environment to port my current project (actually under Windows). So, of course, I would like to continue to use Code::Blocks.
I'm under OS X 10.6.8 Snow Leopard. At this step, I've successfully installed Xcode 4.2, then built wxWidgets 2.9.4 (wxCocoa, 32-bit Intel only, Unicode, Static, Debug and Release, stripped-out wx 2.8 compatibility) for my own projects ; I didn't installed-it, just built.
For Codeblocks, on a first pass, I've taken a try with the yearly build by afb, downloadable from a link in this thread : http://forums.codeblocks.org/index.php/topic,16352.msg110993/topicseen.html#msg110993. But, it sounds unstable on my system : it crashes when I open a project (tried with a minimal one from wizard), even if I disable the maximum of plugins, and it's impossible to reach the wxSmith graphic editor (nothing happens when I click on wxFrame in left pane of resource tab).
So, I've decided to try to build Codeblocks from SVN source. I've successfully built and installed wxMac 2.8.12 as Unicode monolithic dylib 32-bit Release, resulting in "/usr/local/lib/libwx_macu-2.8.0.8.0.dylib". Then, I've checked-out from "svn://svn.berlios.de/codeblocks/trunk" and globally followed general steps described in this tread : http://forums.codeblocks.org/index.php/topic,15108.msg101093.html. So, in condensed, it gives something like this :
Manually added line "m4_include([wxwin.m4])" after the "m4_include([revision.m4])" one in "configure.in".
From working copy of C::B trunk, I've ran :
--- Code: ---#!/bin/sh
cp ../wxMac-2.8.12/wxwin.m4 .
ACLOCAL_FLAGS="-I /usr/share/aclocal"
./bootstrap
arch_flags="-arch i386"
./configure --with-contrib-plugins=all --enable-shared --enable-monolithic --enable-unicode --with-mac --with-opengl --with-png=builtin --with-jpeg=builtin --with-tiff=builtin --with-expat=builtin CFLAGS="$arch_flags" CXXFLAGS="$arch_flags" CPPFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags" OBJCXXFLAGS="$arch_flags"
make
sudo make install
--- End code ---
And during "make", it complains about a method being absent in a class : 'class wxAuiTabCtrl' has no member named 'UnsetToolTip'. Here is full make output (ran on a second pass ; didn't though to save the first one) :
--- Code: ---ELNDESK-OSX:~ eln$ cd "/Users/eln/Downloads/From_SVN_Repos/Codeblocks/Source"
ELNDESK-OSX:Source eln$ make
Making all in src
Making all in include
make all-recursive
Making all in scripting
Making all in squirrel
make[5]: Nothing to be done for `all'.
Making all in sqstdlib
make[5]: Nothing to be done for `all'.
Making all in sqplus
make[5]: Nothing to be done for `all'.
Making all in bindings
make[5]: Nothing to be done for `all'.
Making all in include
make[5]: Nothing to be done for `all'.
make[5]: Nothing to be done for `all-am'.
Making all in tinyxml
make[4]: Nothing to be done for `all'.
Making all in base
Making all in tinyxml
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all-am'.
Making all in build_tools
Making all in autorevision
./auto_revision +int +wx +t ../../.. ../../../src/include/autorevision.h
make[3]: Nothing to be done for `all-am'.
Making all in mime
make[2]: Nothing to be done for `all'.
Making all in sdk
Making all in scripting
Making all in squirrel
make[4]: Nothing to be done for `all'.
Making all in sqstdlib
make[4]: Nothing to be done for `all'.
Making all in sqplus
make[4]: Nothing to be done for `all'.
Making all in bindings
make[4]: Nothing to be done for `all'.
make[4]: Nothing to be done for `all-am'.
Making all in wxscintilla
make[3]: Nothing to be done for `all'.
Making all in wxpropgrid
make[3]: Nothing to be done for `all'.
Making all in resources
Making all in lexers
make[4]: Nothing to be done for `all'.
make[4]: Nothing to be done for `all-am'.
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../src/include -I/usr/lib/wx/include/mac-unicode-debug-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/sdk/wxpropgrid/include -I../../src/include/tinyxml -I../../src/include/scripting/include -I../../src/include/scripting/bindings -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -arch i386 -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -arch i386 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -MT cbauibook.lo -MD -MP -MF .deps/cbauibook.Tpo -c -o cbauibook.lo cbauibook.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src/include -I/usr/lib/wx/include/mac-unicode-debug-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ -I../../src/include -I../../src/sdk/wxscintilla/include -I../../src/sdk/wxpropgrid/include -I../../src/include/tinyxml -I../../src/include/scripting/include -I../../src/include/scripting/bindings -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet -arch i386 -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -arch i386 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -MT cbauibook.lo -MD -MP -MF .deps/cbauibook.Tpo -c cbauibook.cpp -fno-common -DPIC -o .libs/cbauibook.o
cbauibook.cpp: In member function 'void cbAuiNotebook::OnMotion(wxMouseEvent&)':
cbauibook.cpp:408: error: 'class wxAuiTabCtrl' has no member named 'UnsetToolTip'
cbauibook.cpp:419: error: 'class wxAuiTabCtrl' has no member named 'UnsetToolTip'
make[3]: *** [cbauibook.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
ELNDESK-OSX:Source eln$
--- End code ---
So, what does-it means ? Does wxWidgets 2.8.12 not compatible with the SVN Head of 2012/11/29 ? Should I go against wxWidgets 2.9.4 ? If yes, should the wx 2.9.4 I've already built (see my description at top of this post) would be compatible with current Codeblocks SVN or should I build a new one (for example as wxCarbon rather than Cocoa, monolithic dylib rather than multi-libs static) ? What's the up-to-date direction, please ?
--
EDIT : just tried against wxWidgets 2.9.4 unicode dylib 32-bit for x86 Intel and same error : "cbauibook.cpp: In member function 'void cbAuiNotebook::OnMotion(wxMouseEvent&)': cbauibook.cpp:408: error: 'class wxAuiTabCtrl' has no member named 'UnsetToolTip'"
stahta01:
I am primary a Windows person; so all the Mac info is a guess and what I remember from over two years ago.
IIRC, Mac has more than 1 type of wxWidgets that can be built; I think you need the wxGTK version instead of the more common wxMac versions.
afb, is the one who must likely knows the current details.
Tim S.
MortenMacFly:
--- Quote from: eanon on November 30, 2012, 01:41:56 pm ---then built wxWidgets 2.9.4 (wxCocoa, 32-bit Intel only, Unicode, Static, Debug and Release, stripped-out wx 2.8 compatibility) for my own projects ; I didn't installed-it, just built.
--- End quote ---
This is not yet supported. You need to install wxWidgets 2.8.12.
Note that the one shipping with the Mac is usually wx 2.8.8 which is too old, therefore you get this error:
--- Quote from: eanon on November 30, 2012, 01:41:56 pm ---
--- Code: ---#!/bin/sh
cbauibook.cpp: In member function 'void cbAuiNotebook::OnMotion(wxMouseEvent&)':
cbauibook.cpp:408: error: 'class wxAuiTabCtrl' has no member named 'UnsetToolTip'
cbauibook.cpp:419: error: 'class wxAuiTabCtrl' has no member named 'UnsetToolTip'
--- End code ---
--- End quote ---
It seems your build:
--- Quote from: eanon on November 30, 2012, 01:41:56 pm ---So, I've decided to try to build Codeblocks from SVN source. I've successfully built and installed wxMac 2.8.12 as Unicode monolithic dylib 32-bit Release, resulting in "/usr/local/lib/libwx_macu-2.8.0.8.0.dylib".
--- End quote ---
...is not being used, instead the one present in /usr/include and /usr/lib (note the missing "local"). Also, the name "libwx_macu-2.8.0.8.0.dylib" indicates its not 2.8.12 which is weird.
--- Quote from: eanon on November 30, 2012, 01:41:56 pm ---Manually added line "m4_include([wxwin.m4])" after the "m4_include([revision.m4])" one in "configure.in".
From working copy of C::B trunk, I've ran :
--- End quote ---
This is not needed, btw.
So: My guess is that you have the default (wx2.8.8) version installed under /usr/include and /usr/lib which is being used through the builds. Try what you see when you type "wx-config --cflags" on the command line (where it points to).
I don't know the Mac well but when I once tried I simlpy removed the version present in the /usr/include and /usr/lib folders, built the 2.8.12 one under /usr/local (with some parameters and issuing a sudo make install afterwards) and it worked. I recall I needed the unicode flag and the --prefix flag for the configure part of wxWidgets. Check ./configure --help to know the exact names.
eranon:
Thanks for your two replies, Tim and Morten. I'm going to restart from the beginning today, taking care of the key points you indicate, Morten... I'll tell you the result of course...
--
EDIT : At this time, I've built and installed wx 2.8. So, an intermediary point (may help OSX-newbies like me - lol) :
- I've cleaned-up the system removing all wx dylib and headers under /usr/local (and bin/wxrc-28 too)
- To push a little, I've searched for all the file with *wx* in the partition (so, I see some in Xcode tree, OSX SDK 10.5 and 10.6, and also wxPerl and wxPython)... I didn't deleted anything.
- From wxWidgets 2.8.12 source base, I ran this (done manually in terminal, but could be a shell script like this) :
#!/bin/sh
mkdir ./shared_release
cd ./shared_release
../configure CFLAGS="-arch i386" CXXFLAGS="-arch i386" CPPFLAGS="-arch i386" LDFLAGS="-arch i386" OBJCFLAGS="-arch i386" OBJCXXFLAGS="-arch i386" --enable-macosx_arch=i386 --enable-unicode --enable-shared --enable-monolithic --disable-debug --prefix=/usr/local
Also, here, note that I've provided "--prefix=/usr/local", but, from what I've read around, it seems to be the default location where OSX will install anyway. Indicating-it, we're sure !
The final configure report was (copy/paste) :
--- Code: --------------------------------------------------------------------
Configured wxWidgets 2.8.12 for `i686-apple-darwin10.8.0'
Which GUI toolkit should wxWidgets use? mac
Should wxWidgets be compiled into single library? yes
Should wxWidgets be compiled in debug mode? no
Should wxWidgets be linked as a shared library? yes
Should wxWidgets be compiled in Unicode mode? yes
What level of wxWidgets compatibility should be enabled?
wxWidgets 2.4 no
wxWidgets 2.6 yes
Which libraries should wxWidgets use?
jpeg builtin
png builtin
regex builtin
tiff builtin
zlib sys
odbc no
expat sys
libmspack no
sdl no
-----------------------------------------------------------------
--- End code ---
Then, I ran "make" and it produced this content in the "<wx>/shared/release" directory :
--- Code: ---libwx_macu-2.8.0.8.0.dylib
libwx_macu-2.8.0.dylib
libwx_macu-2.8.dylib
libwx_macu-2.8
libwxpng-2.8.a
libwxregexu-2.8.a
libwxtiff-2.8.a
--- End code ---
Finally, I've done a "sudo make install" and things well appeared under /usr/local/lib, include and bin, but the dylib I see here (under /usr/local/lib) are :
--- Code: ---libwx_macu-2.8.0.8.0.dylib
libwx_macu-2.8.0.dylib
libwx_macu-2.8.dylib
--- End code ---
So, why these version numbers in libwx_macu-2.8.0.8.0.dylib and libwx_macu-2.8.0.dylib ? Why not 2.8.12 ? You've seen-it in a first pass, Morten, but, now, I wonder if it's not a problem of versionning in the produced lib (maybe forgotten to update number in 2.8.12 release)... Or, still a conflict (confusion) with something in my system (since it remains wx dylib in the Xcode tree, with SDK's, even if removed at system and local-wide) ? Under windows, produced DLL are numbered 28 : this way, we don't know if it's 2.8.12 or 2.8.n, but we don't care...
Well, I'll run the building sequence for Code::Blocks (ie. bootstrap, configure, make), but I would like to have your opinion on these dylib numbers ? The underlying question being : is that "normal" (the wanted behavior) ?
PS : sorry for eventual typo, I'm writing very quickly since I have to go...
--
EDIT #2 : Back in front of my desk. Well; I've thought in the car :) A "wx-config --version" returns "2.8.12". So, it should mean it's the only one wx lib installed in the system. Right ? Now, I'll check-out a fresh C::B copy and will try to compile again...
--
EDIT #3b : oops, did a long add (EDIT #3), posted and don't see-it... Lost ! Well, in short : I don't remember the exact error, but after a long process (compiling) it stops on error talking about something wrong around DirectoryMonitor. So, compiling failed a new time :(
--
EDIT #4 : OK, i've ran 'make' again and object files being here it has been quick to reach the error I talk above (#3b). Here it is :
--- Code: ---libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../../src/include -I/usr/local/lib/wx/include/mac-unicode-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXMAC__ -I../../../../src/include -I../../../../src/sdk/wxscintilla/include -I../../../../src/include/mozilla_chardet -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -D__FAM__ -MT directorymonitor.lo -MD -MP -MF .deps/directorymonitor.Tpo -c directorymonitor.cpp -fno-common -DPIC -o .libs/directorymonitor.o
directorymonitor.cpp: In member function 'bool wxDirectoryMonitor::Start()':
directorymonitor.cpp:620: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp:621: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp:622: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp: In member function 'void wxDirectoryMonitor::ChangePaths(const wxArrayString&)':
directorymonitor.cpp:629: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp: In destructor 'virtual wxDirectoryMonitor::~wxDirectoryMonitor()':
directorymonitor.cpp:634: warning: possible problem detected in invocation of delete operator:
directorymonitor.cpp:634: warning: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: warning: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp:634: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined.
make[4]: *** [directorymonitor.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
ELNDESK-OSX:Source eln$
--- End code ---
--
EDIT #5 : Using "make -k", compiling is continuing in spite of the error above (EDIT #4)... Will I have a working up-to-date C::B or not ? That is the question ???
--
EDIT #6 : at the end of the process, of course it doesn't compile all... What's the next direction ? If a Mac person involved in Code::Blocks could drive me ? Or, if an OSX binary could be released, say, monthly...
--
EDIT #7 : Some news about the adventure 8) Seeing all compiling errors come from contrib plugins, I'm trying to disable the concerned ones, one by one, using configure options like "--with-contrib-plugins=all,-FileManager,-NassiShneiderman,-SpellChecker".
--
EDIT #8 : succeeded to compile ! Now, I'm going to make install, then, maybe, figure-out how to bundle (if necessary)...
afb:
--- Quote from: eanon on December 01, 2012, 08:32:29 am ---So, why these version numbers in libwx_macu-2.8.0.8.0.dylib and libwx_macu-2.8.0.dylib ? Why not 2.8.12 ? You've seen-it in a first pass, Morten, but, now, I wonder if it's not a problem of versionning in the produced lib (maybe forgotten to update number in 2.8.12 release)... Or, still a conflict (confusion) with something in my system (since it remains wx dylib in the Xcode tree, with SDK's, even if removed at system and local-wide) ? Under windows, produced DLL are numbered 28 : this way, we don't know if it's 2.8.12 or 2.8.n, but we don't care...
Well, I'll run the building sequence for Code::Blocks (ie. bootstrap, configure, make), but I would like to have your opinion on these dylib numbers ? The underlying question being : is that "normal" (the wanted behavior) ?
--- End quote ---
The library version number (sover) is only bumped for binary incompatibilities, so it's up to "8" for release 2.8.12.
For details see: http://svn.wxwidgets.org/viewvc/wx/wxWidgets/branches/WX_2_8_BRANCH/build/bakefiles/version.bkl
And yes, it's "normal". Note that the "real" library is the one with .0.dylib, the other one (.0.8.0.dylib) is a symlink.
--- Quote ---EDIT #2 : Back in front of my desk. Well; I've thought in the car :) A "wx-config --version" returns "2.8.12". So, it should mean it's the only one wx lib installed in the system. Right ? Now, I'll check-out a fresh C::B copy and will try to compile again...
--- End quote ---
Looks OK. You want to use something like --with-wx-config=/usr/local/bin/wx-config to make sure it picks up the right one, and not the /usr/bin/wx-config (2.8.8 debug) that is first in the path.
--- Quote -----
EDIT #3b : oops, did a long add (EDIT #3), posted and don't see-it... Lost ! Well, in short : I don't remember the exact error, but after a long process (compiling) it stops on error talking about something wrong around DirectoryMonitor. So, compiling failed a new time :(
--
EDIT #4 : OK, i've ran 'make' again and object files being here it has been quick to reach the error I talk above (#3b). Here it is :
--- Code: ---libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../../src/include -I/usr/local/lib/wx/include/mac-unicode-release-2.8 -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXMAC__ -I../../../../src/include -I../../../../src/sdk/wxscintilla/include -I../../../../src/include/mozilla_chardet -Ulinux -Uunix -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -D__FAM__ -MT directorymonitor.lo -MD -MP -MF .deps/directorymonitor.Tpo -c directorymonitor.cpp -fno-common -DPIC -o .libs/directorymonitor.o
directorymonitor.cpp: In member function 'bool wxDirectoryMonitor::Start()':
directorymonitor.cpp:620: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp:621: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp:622: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp: In member function 'void wxDirectoryMonitor::ChangePaths(const wxArrayString&)':
directorymonitor.cpp:629: error: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: error: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp: In destructor 'virtual wxDirectoryMonitor::~wxDirectoryMonitor()':
directorymonitor.cpp:634: warning: possible problem detected in invocation of delete operator:
directorymonitor.cpp:634: warning: invalid use of incomplete type 'struct DirMonitorThread'
directorymonitor.h:21: warning: forward declaration of 'struct DirMonitorThread'
directorymonitor.cpp:634: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined.
make[4]: *** [directorymonitor.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
ELNDESK-OSX:Source eln$
--- End code ---
--- End quote ---
Nobody has ported the "FileManager" plugin yet, so it doesn't compile for the Mac...
These are currently on my blacklist: ,-NassiShneiderman,-FileManager,-spellchecker
--- Quote -----
EDIT #5 : Using "make -k", compiling is continuing in spite of the error above (EDIT #4)... Will I have a working up-to-date C::B or not ? That is the question ???
--
EDIT #6 : at the end of the process, of course it doesn't compile all... What's the next direction ? If a Mac person involved in Code::Blocks could drive me ? Or, if an OSX binary could be released, say, monthly...
--- End quote ---
More like yearly now, but anyway. The big challenge is getting it ported to wxOSX/Cocoa, so it can support Mac OS X later than 10.6...
This is also a requirement for supporting x86_64, in addition to the i386 (one can probably drop the ppc)
--- Quote -----
EDIT #7 : Some news about the adventure 8) Seeing all compiling errors come from contrib plugins, I'm trying to disable the concerned ones, one by one, using configure options like "--with-contrib-plugins=all,-FileManager,-NassiShneiderman,-SpellChecker".
--
EDIT #8 : succeeded to compile ! Now, I'm going to make install, then, maybe, figure-out how to bundle (if necessary)...
--- End quote ---
Seems like you succeeded! The old bundle docs should be on the Wiki, basically relocates everything to use @executable_path.
http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Mac_OS_X
Navigation
[0] Message Index
[#] Next page
Go to full version