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

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$ 

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]

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.

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:

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'

It seems your build:

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".

...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.

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 :

This is not needed, btw.

So: My guess is that you have the default (wx2.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
-----------------------------------------------------------------

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

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

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$ 

--
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 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]

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) ?

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.

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...

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.

--
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$ 

Nobody has ported the "FileManager" plugin yet, so it doesn't compile for the Mac...

These are currently on my blacklist: ,-NassiShneiderman,-FileManager,-spellchecker

--
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...

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)

--
EDIT #7 : Some news about the adventure 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)...

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

[eranon]

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) :

Code

#!/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...

[MortenMacFly]

Guys, that's nice to read. The last time I was on a Mac I basically gave up when trying to create an app bundle.

Could you please transfer this into the WiKi to the right place? I would like to give it a try next time I get my hand on a Mac... It was kind of frustrating last time that I were able to compile, but not package.

[eranon]

Yep, for sure, we're happy when it runs under OSX, Morten ) Not that it's less well or more difficult than Windows, but what I discover since some days is that there're a lot less information around Mac than others OS'es. For example, I'm currently on an attempt (well, in fact I've the obligation to achieve the task - lol) to build a first minimal project, coming from C::B wizard... And I've a (I hope) last blocking point I express here : http://forums.codeblocks.org/index.php/topic,17193.0.html.

Well, so, in two steps :

1) At this time, my bundle is not strictly correct since I didn't solved relocations in full (I mean about core C::B and contrib plugins). So, it remains to fix the dylibbundler/install_name_tool stage, taking care of all.

2) About a guideline in wiki, why not (it would be an honor), but the real fact is that I'm more than late on my projects (I'm currently working on a 1.0 of a commercial software on a side and an open-source (not in C++, so not easy to switch several times per day) I've promised to a community for... this month, oops ; quite ready but I've to comment full source and add multilingual feature). Well, here is what I can do : once I've published this repo and reached 1.0 alpha on my current development, I write do something for the wiki from zero to first OSX minimal project built (so, build wxWidgets, build C::B SVN, create first project) ;o) But awaiting, of course, I can send you binaries or material you need/wish...

[afb]

Guys, that's nice to read. The last time I was on a Mac I basically gave up when trying to create an app bundle.

Could you please transfer this into the WiKi to the right place? I would like to give it a try next time I get my hand on a Mac... It was kind of frustrating last time that I were able to compile, but not package.

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.

Since I built wxWidgets as one "monolithic" library, including all the dependencies that it needs, I don't think
there's any need for something like dylibbundler. Just need to copy the files and run install_name_tool ?

[Martin K.]

Hi,

Has anyone any experience on OS-X 10.8?
I have build wxWidgets 2.8.12 with the 10.6 SDK, that works, even the samples are running. But i fail while compiling Code::Blocks. It seems to use the 10.8 SDK which is not compatible with wxWidgets. Any hints so i can try this again this evening?

Martin

[eranon]

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")

@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 :

Code

- Compiler : -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 
- Linker : -syslibroot,/Developer/SDKs/MacOSX10.5.sdk

[Martin K.]

@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 :

Code

- 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.
Unfortunately the 12.11 doesn't run on OS-X 10.8.2, it crashes after opening a source file. If i could compile Code::Blocks, than i whould have a look on it.

Martin

[eranon]

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) :

Code

--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 :

Code

- 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).

[Martin K.]

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

[stahta01]

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

Code

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.

[Martin K.]

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

Code

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.

No, this does not help. The configure scripts are having no support for such a configuration. I cannot build a 1.6 targeted 32 bit codeblocks on a 10.8 64 Bit system. The wxWidgets configuration.in has such support, but i don't know how to insert it into the codeblocks configuration.in file.
some autoconf guru around here?

Martin

[eranon]

Of course, you have to ensure that the library and the project using the library (here Codeblocks) have been built targetting the same architecture. So, did you use something related to the architecture (32-bit or 64-bit, Intel/Motorola PPC) in the framework of CFLAG/CXXFLAGS/LDFLAGS during configure of both wxWidgets and Code::Blocks (I mean something like "arch i386) ?

Second question : does OS X 10.8 still 32-bit able (don't know by myself since I'm under 10.6) ?