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 :
#!/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
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) :
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$
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'"
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) :
-----------------------------------------------------------------
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
-----------------------------------------------------------------
Then, I ran "make" and it produced this content in the "<wx>/shared/release" directory :
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
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 :
libwx_macu-2.8.0.8.0.dylib
libwx_macu-2.8.0.dylib
libwx_macu-2.8.dylib
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 :
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$
--
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)...
Thanks a lot for your point of view on my roadmovie, afb :) Some points are more clear in my mind, now (like the version numbering).
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
Today, I've read a lot of things about bundle, including the URL you give me here. At this time, after some trials and fails (like crash or not any plugin), I have a working bundle (not seen in depth, I'll be sure during real use), but, since I didn't relocated everyhing I think main executables use the dylib from /usr/local.
In fact, at the beginning I've used the install_name_tool. It worked, but beside of this, my inner tree - inside bundle - was wrong and I didn't had any plugin... So, I've fixed the tree looking in your yearly build and started to search for a workaround about the "manual" part with install_name_tool, and I found another one, a layer above, called dylibbundler by Auria which check the dependencies, copy the dylib and fix the reference in the executable. In the spirit, it sounds magic, but when you don't know the organization of a project (my case about C::B), it becomes quickly complicated to decide what and when to manage things...
So, here is my last script, giving me a "working bundle", but without full relocation (and if you uncomment the commented lines about dylibbundler, Codeblocks crashes during start-up) :
#!/bin/sh
prefix="/usr/local"
echo Build an OSX CodeBlock bundle in current directory
echo --------------------------------------------------
echo SVN copy must be in subdir called Source
rm -rf codeblocks.app
echo Build bundle tree
mkdir codeblocks.app
mkdir codeblocks.app/Contents
mkdir codeblocks.app/Contents/MacOS
mkdir codeblocks.app/Contents/MacOS/wxContribItems
mkdir codeblocks.app/Contents/Resources
mkdir codeblocks.app/Contents/Resources/share
mkdir codeblocks.app/Contents/Resources/share/codeblocks
mkdir codeblocks.app/Contents/Resources/English.lproj
echo Set metadata
echo -n 'APPL????' > codeblocks.app/Contents/PkgInfo
cp ./Source/codeblocks.plist codeblocks.app/Contents/Info.plist
# cp version.plist codeblocks.app/Contents/
# cp InfoPlist.strings codeblocks.app/Contents/Resources/English.lproj/
echo Set main executables
cp ${prefix}/bin/codeblocks ./codeblocks.app/Contents/MacOS/CodeBlocks
cp ${prefix}/bin/codesnippets ./codeblocks.app/Contents/MacOS/
cp ${prefix}/bin/cb_share_config ./codeblocks.app/Contents/MacOS/
cp ${prefix}/bin/cb_console_runner ./codeblocks.app/Contents/MacOS/
cp ${prefix}/lib/libcodeblocks.0.dylib ./codeblocks.app/Contents/MacOS/
cp ${prefix}/lib/libwxsmithlib.0.dylib ./codeblocks.app/Contents/MacOS/
cp ${prefix}/lib/libwx_macu-2.8.0.dylib ./codeblocks.app/Contents/MacOS/
echo Add contrib plugins
cp ${prefix}/lib/codeblocks/wxContribItems/libwxchartctrl.0.dylib ./codeblocks.app/Contents/MacOS/wxContribItems/
cp ${prefix}/lib/codeblocks/wxContribItems/libwxcustombutton.0.dylib ./codeblocks.app/Contents/MacOS/wxContribItems/
cp ${prefix}/lib/codeblocks/wxContribItems/libwxflatnotebook.0.dylib ./codeblocks.app/Contents/MacOS/wxContribItems/
cp ${prefix}/lib/codeblocks/wxContribItems/libwximagepanel.0.dylib ./codeblocks.app/Contents/MacOS/wxContribItems/
cp ${prefix}/lib/codeblocks/wxContribItems/libwxkwic.0.dylib ./codeblocks.app/Contents/MacOS/wxContribItems/
cp ${prefix}/lib/codeblocks/wxContribItems/libwxled.0.dylib ./codeblocks.app/Contents/MacOS/wxContribItems/
cp ${prefix}/lib/codeblocks/wxContribItems/libwxspeedbutton.0.dylib ./codeblocks.app/Contents/MacOS/wxContribItems/
cp ${prefix}/lib/codeblocks/wxContribItems/libwxtreelist.0.dylib ./codeblocks.app/Contents/MacOS/wxContribItems/
echo Resolve dependencies
#dylibbundler -of -b -x ./codeblocks.app/Contents/MacOS/wxContribItems/libwxchartctrl.0.dylib -x ./codeblocks.app/Contents/MacOS/wxContribItems/libwxcustombutton.0.dylib -x ./codeblocks.app/Contents/MacOS/wxContribItems/libwxflatnotebook.0.dylib -x ./codeblocks.app/Contents/MacOS/wxContribItems/libwximagepanel.0.dylib -x ./codeblocks.app/Contents/MacOS/wxContribItems/libwxkwic.0.dylib -x ./codeblocks.app/Contents/MacOS/wxContribItems/libwxled.0.dylib -x ./codeblocks.app/Contents/MacOS/wxContribItems/libwxspeedbutton.0.dylib -x ./codeblocks.app/Contents/MacOS/wxContribItems/libwxtreelist.0.dylib -d ./codeblocks.app/Contents/MacOS/wxContribItems/
#dylibbundler -of -b -x ./codeblocks.app/Contents/MacOS/CodeBlocks -x ./codeblocks.app/Contents/MacOS/codesnippets -x ./codeblocks.app/Contents/MacOS/cb_share_config -x ./codeblocks.app/Contents/MacOS/cb_console_runner -x ./codeblocks.app/Contents/MacOS/libcodeblocks.0.dylib -x ./codeblocks.app/Contents/MacOS/libwxsmithlib.0.dylib -x ./codeblocks.app/Contents/MacOS/libwx_macu-2.8.0.dylib -d ./codeblocks.app/Contents/MacOS/
echo Add resources
cp ./Source/src/src/resources/icons/*.icns codeblocks.app/Contents/Resources/
cp -R ${prefix}/share/codeblocks/ ./codeblocks.app/Contents/Resources/share/codeblocks/
cp -R ${prefix}/lib/codeblocks/plugins/*.so ./codeblocks.app/Contents/Resources/share/codeblocks/
for dotso in ./codeblocks.app/Contents/Resources/share/codeblocks/*.so
do
echo $dotso
install_name_tool -change ${prefix}/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib $dotso
install_name_tool -change ${prefix}/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib $dotso
install_name_tool -change ${prefix}/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib $dotso
install_name_tool -change ${prefix}/lib/codeblocks/wxContribItems/libwxchartctrl.0.dylib @executable_path/wxContribItems/libwxchartctrl.0.dylib $dotso
install_name_tool -change ${prefix}/lib/codeblocks/wxContribItems/libwxcustombutton.0.dylib @executable_path/wxContribItems/libwxcustombutton.0.dylib $dotso
install_name_tool -change ${prefix}/lib/codeblocks/wxContribItems/libwxflatnotebook.0.dylib @executable_path/wxContribItems/libwxflatnotebook.0.dylib $dotso
install_name_tool -change ${prefix}/lib/codeblocks/wxContribItems/libwximagepanel.0.dylib @executable_path/wxContribItems/libwximagepanel.0.dylib $dotso
install_name_tool -change ${prefix}/lib/codeblocks/wxContribItems/libwxkwic.0.dylib @executable_path/wxContribItems/libwxkwic.0.dylib $dotso
install_name_tool -change ${prefix}/lib/codeblocks/wxContribItems/libwxled.0.dylib @executable_path/wxContribItems/libwxled.0.dylib $dotso
install_name_tool -change ${prefix}/lib/codeblocks/wxContribItems/libwxspeedbutton.0.dylib @executable_path/wxContribItems/libwxspeedbutton.0.dylib $dotso
install_name_tool -change ${prefix}/lib/codeblocks/wxContribItems/libwxtreelist.0.dylib @executable_path/wxContribItems/libwxtreelist.0.dylib $dotso
done
unset prefix
echo Done !
echo codeblocks.app created beside $0
What do you think about this ? Next step is, of course, to obtain a real standalone bundle (independent of my own system context), succeeding to use dylibbundler or being back with install_name_tool...
I don't think the information on the wiki is that outdated, it's what I did for the CodeBlocks.app myself...
But one might emphasis how to do it with llvm-gcc-4.2 and 10.6.sdk in addition to gcc-4.0 and 10.4u.sdk.
In fact, in my mind, it's unbelievable it doesn't exist a standalone tool to create a bundle in some clicks ; producing a script which could be ran as automatic post-build step has done by Xcode. Since I look into Mac OS X (ie. some days), I'm impressed by the Apple attempts to keep control and do things appear more complex than it is in reality, while, concretely, a ".app" file is just an archive with its inner tree and this objective to limit external references to stock system libs (oops, "framework") 8)
@Martin : about SDK to use, you have these options (I, myself, indicated the 10.5 being under 10.6), but maybe you will receive more replies opening a new specific thread :
- Compiler : -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
- Linker : -syslibroot,/Developer/SDKs/MacOSX10.5.sdk
where does i have to set this options? i have tried it on the configure commandline and it doesn't work.
Hmmm, in my case, I didn't need to use them to compile Codeblocks against wxWidgets 2.8 dylib, but for my own project, against wxWidgets 2.9 static, I do this to stay compatible with OSX 10.5 :
wxWidgets is configured with options including those (doing the ./configure, make, sudo make install from command line) :
--with-macosx-version-min=10.5 --with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk
Then, my project (linked with the wxWidgets above) includes the options as I told you in my previous post :
- C::B Compiler options : -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
- C::B Linker options : -syslibroot,/Developer/SDKs/MacOSX10.5.sdk
Also, of course, take care to have the right SDK in right path. For example, in my case, being under OSX 10.6 with Xcode 4.2, the OSX SDK 10.5 was not delivered automatically : I've had to copy it by myself beside the SDK 10.6.
--
EDIT : also, having compiled C::B from SVN source, I have to say that this SVN 8643 sounds very stable until now on my machine. Only 3 contrib plugins which didn't compile and a Lib Finder which doesn't work (does nothing).
I'am a little bit deeper on this.
The difference is something in the configure script. config.log of codeblocks configure notes:
configure:2226: checking build system type
configure:2244: result: x86_64-apple-darwin12.2.0
while config.log of wxwidgets configure notes:
configure:1725: checking build system type
configure:1743: result: i686-apple-darwin12.2.0
i gave the same flags to both. And here i'm totally lost, i know nothing about autoconf
Martin
From http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Mac_OS_X#FYI:_32-bit_or_64-bit (http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Mac_OS_X#FYI:_32-bit_or_64-bit)
mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --with-contrib-plugins=all
cd ..
What did you use for target? I would try "i686-apple-darwin12.2.0" for target and maybe for host.
Not sure what the host should be.
Tim S.