Difference between revisions of "Installing Code::Blocks from source on Mac OS X"

From Code::Blocks
m (made readable)
 
(173 intermediate revisions by 4 users not shown)
Line 2: Line 2:
 
[[Category:Installing Code::Blocks from source]]
 
[[Category:Installing Code::Blocks from source]]
 
These are instructions on how to build Code::Blocks under Apple Mac OS X.
 
These are instructions on how to build Code::Blocks under Apple Mac OS X.
−
They have been tested under Mac OS X version 10.3, but should work under
+
They have been tested under Mac OS X version 10.4 (PowerPC and Intel),
−
Mac OS X 10.4 (PowerPC and Intel) and old Mac OS X 10.2 and 10.1 as well.
+
and should work similarly on the newer Mac OS X 10.5 and 10.6 as well.
  
 
We will be building everything from scratch using the source code, and
 
We will be building everything from scratch using the source code, and
 
not use any available package managers like
 
not use any available package managers like
−
[http://darwinports.opendarwin.org DarwinPorts],
+
[http://www.macports.org MacPorts],
 
[http://fink.sourceforge.net/ Fink],
 
[http://fink.sourceforge.net/ Fink],
 
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
 
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
Line 13: Line 13:
 
Packaging can be done later, once it has reached a more stable release.
 
Packaging can be done later, once it has reached a more stable release.
  
−
== Install Xcode Tools ==
+
Update: building for MacPorts can be found at the end of the document.
  
−
If they didn't come bundled with Mac OS X, get the Xcode Tools (or Developer Tools for older Mac OS X) from:
+
== Install Developer Tools ==
  
−
http://developer.apple.com/
+
If they didn't come bundled with Mac OS X, get the Xcode Tools (or Developer Tools for older Mac OS X) from http://developer.apple.com/tools/ or from your install disk.
  
 
This will install Apple versions of:
 
This will install Apple versions of:
  
−
* http://www.gnu.org/software/gcc/ (GNU Compiler Collection)
+
* http://www.gnu.org/software/gcc/ (GNU Compilers)
 
* http://www.gnu.org/software/gdb/ (GNU Debugger)
 
* http://www.gnu.org/software/gdb/ (GNU Debugger)
 
* http://www.gnu.org/software/make/ (GNU Make)
 
* http://www.gnu.org/software/make/ (GNU Make)
  
−
Note: 2006/04
+
Apple regularly pulls all older links in order to promote newer Mac OS X, but all the
−
Apple pulled all the old links in order to promote Mac OS X 10.4, but all the
 
 
old developer tools can be downloaded from ADC at http://connect.apple.com/
 
old developer tools can be downloaded from ADC at http://connect.apple.com/
  
 
You need a (free) developer registration with Apple first, in order to log in there.
 
You need a (free) developer registration with Apple first, in order to log in there.
−
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, latest Dev Tools.
+
For Mac OS X 10.4, you want (at least) Xcode 2.2, since earlier versions were buggy.
 +
 
 +
[http://www.mac-how.net Mac How]
  
 
== Check Autotools versions ==
 
== Check Autotools versions ==
Line 36: Line 37:
 
Depending on your OS version, you might need to download and compile new versions of these:
 
Depending on your OS version, you might need to download and compile new versions of these:
  
−
* http://www.gnu.org/software/autoconf/
+
* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
−
* http://www.gnu.org/software/automake/
+
* http://www.gnu.org/software/automake/ (GNU Automake)
−
* http://www.gnu.org/software/libtool/
+
* http://www.gnu.org/software/libtool/ (GNU Libtool)
  
−
Check what you have, with <tt>--version</tt> (note that GNU libtool is called "glibtool" on Mac)
+
Check what you have, with <tt>--version</tt> (note that GNU libtool is called "glibtool" on Mac OS X)
  
 
Currently Code::Blocks requires versions:
 
Currently Code::Blocks requires versions:
 
* autoconf 2.50+
 
* autoconf 2.50+
−
* automake 1.7+
+
* automake 1.7+ (1.9+ needed in order to build the dist tarball)
−
* libtool 1.4+
+
* libtool 1.4+ (1.5.8+ highly recommended to get some bug fixes)
 +
 
 +
=== Automake example ===
  
−
For Mac OS X 10.3, you will only need an upgraded (local) installation of automake 1.7.x.
+
For Mac OS X 10.4, you will only need an upgraded (local) installation of automake 1.9.x.
  
−
You can download "automake-1.7.9.tar.gz" and configure and install it with something like:
+
You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.9.6.tar.gz automake-1.9.6.tar.gz]" and configure and install it with something like:
  
 
<pre>
 
<pre>
−
./configure --program-suffix=-1.7
+
./configure --prefix=/usr/local --program-suffix=-1.9
 
make
 
make
 
sudo make install
 
sudo make install
 +
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.9/
 
</pre>
 
</pre>
  
−
Since it's now known as "automake-1.7", it won't interfere with the regular "automake"
+
Since it's now known as "automake-1.9", it won't interfere with the regular "automake"
  
−
== Universal Binaries ==
+
If you would rather have the new version to be called when calling "automake", let it install into /usr/local and put /usr/local/bin before /usr/bin in your PATH.
  
−
If you are building for Mac OS X 10.4, you might want to build "[http://www.apple.com/universal/ Universal Binaries ]"
+
=== Libtool example ===
−
These are binaries that contain code for both PowerPC ("powerpc") and Intel ("i686")
+
Download [http://www.gnu.org/software/libtool/ libtool] source. The following instructions will overwrite your current version of libtool with the one you just downloaded.
 +
<pre>
 +
cd /libtool-*/
 +
./configure --prefix=/usr --program-prefix=g
 +
make
 +
sudo make install
 +
</pre>
 +
 
 +
Note that this will replace the system version of glibtool, which might have some compatibility issues with building other software.
 +
 
 +
== FYI: Universal Binaries ==
 +
 
 +
If you are building for Mac OS X 10.4 or later, you might want to build "[http://www.apple.com/universal/ Universal Binaries ]"
 +
These are binaries that contain code for both PowerPC ("ppc" arch) and Intel ("i386" arch)
  
 
The basic flags that needs to be added are:
 
The basic flags that needs to be added are:
 
<pre>
 
<pre>
 
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
 
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
 +
 +
CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
 
</pre>
 
</pre>
 
(You only need the sysroot parameter on PowerPC Macintosh, not on a Intel Macintosh)
 
(You only need the sysroot parameter on PowerPC Macintosh, not on a Intel Macintosh)
Line 73: Line 92:
 
Usually it's easiest to build one version for "powerpc-apple-darwin8",
 
Usually it's easiest to build one version for "powerpc-apple-darwin8",
 
and one version for "i686-apple-darwin8", and then merge them with "[http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/lipo.1.html lipo]"
 
and one version for "i686-apple-darwin8", and then merge them with "[http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/lipo.1.html lipo]"
 +
 +
<pre>
 +
./configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8
 +
 +
./configure --host=i686-apple-darwin8 --target=i686-apple-darwin8
 +
</pre>
  
 
Some caveats:
 
Some caveats:
Line 82: Line 107:
 
Binaries from "configure"-based Open Source Projects
 
Binaries from "configure"-based Open Source Projects
  
−
== Build wxWidgets 2.6 ==
+
== FYI: Compilers ==
 +
 
 +
When building for older versions of the SDK, you want to make sure to use the same compiler.
  
−
=== Download the Mac release ===
+
<pre>
 +
CC = gcc-4.0
  
−
http://wxwidgets.org/downloads/#latest_stable
+
CXX = g++-4.0
 +
</pre>
 +
 
 +
Mac OS X 10.6 has GCC 4.2 as the default compiler, which won't work for the Mac OS X 10.4 SDK.
 +
 
 +
== FYI: ANSI or UNICODE ==
 +
 
 +
For the moment we are using "ANSI" (--disable-unicode, default) for Mac OS X 10.3 and earlier,
 +
and "UNICODE" (--enable-unicode, optional) for Mac OS X 10.4 and later.
 +
 
 +
See http://www.wxwidgets.org/manuals/stable/wx_unicode.html#unicodeandansi
 +
 
 +
== FYI: 32-bit or 64-bit ==
 +
 
 +
Code::Blocks currently uses wxMac (wxOSX/Carbon), which is 32-bit only. So it's not possible to build for "x86_64".
 +
 
 +
When Code::Blocks (and requirements) has been updated to use wxOSX/Cocoa, then a 64-bit version might be built too.
 +
 
 +
== Build wxWidgets ==
 +
 
 +
=== Download the source code ===
 +
 
 +
Download the tarball for the wxMac release:
 +
 
 +
http://wxwidgets.org/downloads/
 +
 
 +
=== Apply necessary patches ===
 +
 
 +
Don't forget to apply any released patches!
 +
 
 +
http://wxwidgets.org/downloads/patch.htm
  
 
=== Configure and (GNU) Make ===
 
=== Configure and (GNU) Make ===
  
 
<pre>
 
<pre>
−
./configure --enable-shared --enable-monolithic --with-opengl --with-mac \
+
mkdir mac-build
−
             --with-png=builtin --with-tiff=builtin --with-jpeg=builtin && make
+
cd mac-build
 +
../configure --enable-shared --enable-monolithic --enable-unicode --with-mac --with-opengl \
 +
             --with-png=builtin --with-jpeg=builtin --with-tiff=builtin --with-expat=builtin
 +
nice make
 
</pre>
 
</pre>
  
 
note: the easiest way to build a Universal Binary with wxWidgets is
 
note: the easiest way to build a Universal Binary with wxWidgets is
−
the new flag: --enable-universal_binary (you need wxWidgets 2.6.3+)
+
the new flag: --enable-universal_binary (you need wxWidgets 2.6.4+)
 +
 
 +
<pre>
 +
--enable-universal_binary --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk --with-macosx-version-min=10.4
 +
</pre>
  
 
=== Install into Destination ===
 
=== Install into Destination ===
Line 103: Line 168:
 
sudo make install
 
sudo make install
 
</pre>
 
</pre>
 +
 +
== Bundle library for Mac ==
 +
 +
To avoid having the Code::Blocks user having to compile or install wxWidgets themselves,
 +
we can bundle it with our application so that it is contained in the application bundle.
 +
This could also be done by statically linking wxWidgets, but with dynamic linking we can
 +
share the wxWidgets library between all applications using wxWidgets (not just Code::Blocks)
 +
 +
 +
=== Way One: Library (dynamic) ===
 +
 +
<pre>
 +
/usr/local/include/wx-2.8/wx/wx.h
 +
/usr/local/lib/libwx_macu-2.8.dylib -> libwx_macu-2.8.0.dylib
 +
/usr/local/lib/libwx_macu-2.8.0.dylib -> libwx_macu-2.8.0.6.0.dylib
 +
/usr/local/lib/libwx_macu-2.8.0.6.0.dylib
 +
</pre>
 +
 +
To bundle our shared library with the application, we include it in "MacOS" and change the path:
 +
 +
<pre>
 +
install_name_tool -id @executable_path/libwx_macu-2.8.0.dylib
 +
</pre>
 +
 +
@executable_path will be replaced with e.g. /Developer/Applications/CodeBlocks.app/Contents/MacOS
 +
 +
=== Way Two: Framework (bundle) ===
 +
 +
<pre>
 +
/Library/Frameworks/wx.framework/Headers -> Versions/Current/Headers
 +
/Library/Frameworks/wx.framework/wx -> Versions/Current/wx
 +
/Library/Frameworks/wx.framework/Versions/Current -> 2.8
 +
/Library/Frameworks/wx.framework/Versions/2.8/Headers/wx.h
 +
/Library/Frameworks/wx.framework/Versions/2.8/wx  -> libwx_macu-2.8.0.dylib
 +
/Library/Frameworks/wx.framework/Versions/2.8/libwx_macu-2.8.0.dylib  -> libwx_macu-2.8.0.6.0.dylib
 +
/Library/Frameworks/wx.framework/Versions/2.8/libwx_macu-2.8.0.6.0.dylib
 +
</pre>
 +
 +
To bundle our framework with the application, we include it in "Frameworks" and change the path:
 +
 +
<pre>
 +
install_name_tool -id @executable_path/../Frameworks/wx.framework/Versions/2.8/libwx_macu-2.8.0.dylib
 +
</pre>
 +
 +
This way it will first look in the framework path (-F), and then in for the shared library path (-L) as usual.
  
 
== Install Subversion client ==
 
== Install Subversion client ==
 +
 +
On Mac OS X 10.4, you need to install the Subversion (svn) program:
  
 
http://subversion.tigris.org/
 
http://subversion.tigris.org/
 +
 +
Note: you need SVN for the Code::Blocks revision scripts to work!
  
 
== Build CodeBlocks from SVN ==
 
== Build CodeBlocks from SVN ==
Line 113: Line 227:
  
 
https://www.codeblocks.org/source_code.shtml
 
https://www.codeblocks.org/source_code.shtml
 +
 +
<pre>
 +
svn checkout svn://svn.berlios.de/codeblocks/trunk
 +
cd trunk
 +
</pre>
 +
 +
=== Apply necessary patches ===
 +
 +
For a list of all available patches, see:
 +
 +
http://developer.berlios.de/patch/?group_id=5358
 +
 +
You might need to convert line endings from DOS to Unix first.
  
 
=== Bootstrap with Autotools ===
 
=== Bootstrap with Autotools ===
  
−
The "bootstrap" script doesn't work on Mac OS X, so do it manually:
+
You need to use the newer version of automake (see above), for the "bootstrap". (OS X 10.5 users may have recent enough autotools so they may not need to install them)
  
 
<pre>
 
<pre>
−
./update_revision.sh
+
# if you installed newer autotools under names with suffixes.
−
glibtoolize --force --copy && \
+
export AUTOMAKE=automake-1.9
−
aclocal-1.7 && \
+
export ACLOCAL=aclocal-1.9
−
cat /usr/share/aclocal/libtool.m4 >> aclocal.m4 && \
+
 
−
autoheader && \
+
# do bootstrap. you may need to adapt /usr/share/aclocal
−
automake-1.7 --include-deps --add-missing --foreign --copy && \
+
# to whatever other location you may use
−
autoconf
+
# (for instance, in my case, /usr/local/share/aclocal)
 +
ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
 
</pre>
 
</pre>
  
−
=== Configure ===
+
=== Mono Fix ===
 +
 
 +
If you have the Mono.framework installed, then it probably set up a symlink like:
  
 
<pre>
 
<pre>
−
LDFLAGS="`wx-config --libs`" ./configure --disable-code-completion
+
/usr/bin/pkg-config -> /Library/Frameworks/Mono.framework/Commands/pkg-config
 
</pre>
 
</pre>
  
−
Note: all the plugins fail to link on Mac OS X, since codeblocks refers to wxWidgets libs
+
Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.
−
(this is why there is an extra LDFLAGS invocation in the above, until it has been fixed)
+
 
 +
=== Configure ===
  
 
<pre>
 
<pre>
−
ld: object_file illegal reference to symbol: ***
+
./configure --with-contrib-plugins=all
−
defined in indirectly referenced dynamic library: ***
 
 
</pre>
 
</pre>
  
−
Note: couldn't get the code completion code to work, so disabling it (for now, rev 2886)
+
Note: the easiest way to build a Universal Binary for Code::Blocks is to build once for PowerPC (-arch ppc) and once for Intel (-arch i386), and then merge them (with lipo) afterwards.
−
It seems that this only happens with old GCC 3.3, since it did build OK with GCC 4.0...
 
  
 
<pre>
 
<pre>
−
nativeparser.cpp: In member function `size_t
+
mkdir ppc-build
−
  NativeParser::FindAIMatches(Parser*, std::queue<ParserComponent,
+
cd ppc-build
−
  std::deque<ParserComponent, std::allocator<ParserComponent> > >,
+
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --with-contrib-plugins=all
−
  TokenIdxSet&, int, bool, bool, bool, short int, TokenIdxSet*)':
+
cd ..
−
nativeparser.cpp:1379: error: no match for `std::_Rb_tree_iterator<int, const
+
 
−
  int&, const int*>& == int' operator
+
mkdir x86-build
−
nativeparser.cpp:1381: error: no match for `std::_Rb_tree_iterator<int, const
+
cd x86-build
−
  int&, const int*>& != int' operator
+
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --with-contrib-plugins=all
−
nativeparser.cpp:1394: error: no match for `std::_Rb_tree_iterator<int, const
+
cd ..
−
  int&, const int*>& == int' operator
 
 
</pre>
 
</pre>
  
−
Note: the easiest way to build a Universal Binary for Code::Blocks is to build once
+
Note: You need to patch the location of the pre-compiled headers, or it will generate them in the same place for both arch.
−
for PowerPC (-arch ppc) and once for Intel (-arch i386), and then merge them afterwards.
 
  
 
=== Tiger Fix ===
 
=== Tiger Fix ===
Line 191: Line 318:
  
 
=== (GNU) Make ===
 
=== (GNU) Make ===
 +
 +
"nice" isn't strictly needed, it just makes the compile run at a lower process priority
 +
 +
<pre>
 +
nice make
 +
</pre>
 +
 +
For the Universal Binary build:
  
 
<pre>
 
<pre>
 +
cd ppc-build
 +
nice make
 +
cd ..
 +
 +
cd x86-build
 
nice make
 
nice make
 +
cd ..
 
</pre>
 
</pre>
  
 
=== Install into Destination ===
 
=== Install into Destination ===
 +
 +
"sudo" asks you for an admin password, in order to get install permissions
  
 
<pre>
 
<pre>
 
sudo make install
 
sudo make install
 
</pre>
 
</pre>
 +
 +
For the Universal Binary build:
 +
 +
<pre>
 +
cd ppc-build
 +
make install DESTDIR=/tmp/ppc
 +
cd ..
 +
 +
cd x86-build
 +
make install DESTDIR=/tmp/x86
 +
cd ..
 +
 +
lipomerge /tmp/ppc /tmp/x86 /tmp/fat
 +
</pre>
 +
 +
Where "lipomerge" is a custom shell script:
 +
 +
* http://www.algonet.se/~afb/wx/lipomerge
  
 
== Bundle application for Mac ==
 
== Bundle application for Mac ==
Line 210: Line 371:
 
The old resources are handy while developing, while bundles are more suitable for release.
 
The old resources are handy while developing, while bundles are more suitable for release.
  
−
=== Way 1. Mac OS (resource) ===
+
Note: You '''need''' to use either of these methods, or your application will launch
 +
in the background behind all other windows and will be unable to receive any events!
 +
 
 +
=== Way One: Mac OS (resource) ===
  
 
http://developer.apple.com/documentation/Carbon/Reference/Resource_Manager/
 
http://developer.apple.com/documentation/Carbon/Reference/Resource_Manager/
  
−
Handy while developing, as you only need to add an icon.
+
Handy while developing, as you don't need to create a whole bundle.
−
 
 
−
Files needed:
 
−
* http://www.algonet.se/~afb/wx/CodeBlocks.r.gz (Rez icon, gzipped)
 
  
 
First we install the program to the PREFIX directory of your choice:
 
First we install the program to the PREFIX directory of your choice:
Line 227: Line 388:
 
</pre>
 
</pre>
  
−
Add a custom icon to the application, and make it receive events:
+
Note: on the Intel Macintoshes, the icon comes up as "broken"
−
 
+
(apparently it assumes that all apps with resforks are Classic)
−
<pre>
 
−
gunzip CodeBlocks.r.gz
 
−
sudo /Developer/Tools/Rez -d __DARWIN__ -t APPL -d __WXMAC__ \
 
−
                          CodeBlocks.r Carbon.r -o $PREFIX/bin/codeblocks
 
−
sudo /Developer/Tools/SetFile -a C $PREFIX/bin/codeblocks
 
−
</pre>
 
−
 
 
−
Without the icon part, this could also have be written as just:
 
−
 
 
−
<pre>
 
−
sudo `wx-config --rezflags` $PREFIX/bin/codeblocks
 
−
</pre>
 
  
 
Start the application with a small prefix shell wrapper like this:
 
Start the application with a small prefix shell wrapper like this:
Line 251: Line 400:
 
</pre>
 
</pre>
  
 +
You don't need the "DYLD_LIBRARY_PATH" stuff,
 +
if you are installing to a system directory.
 +
 +
==== Common PREFIX Settings ====
 +
 +
Local: <tt>PREFIX=/usr/local</tt>
 +
 +
System: <tt>PREFIX=/usr</tt>
 +
 +
MacPorts: <tt>PREFIX=/opt/local</tt>
 +
 +
Fink: <tt>PREFIX=/sw</tt>
  
−
=== Way 2. NeXT (bundle) ===
+
=== Way Two: NeXT (bundle) ===
  
 
http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/
 
http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/
Line 259: Line 420:
  
 
Files needed:
 
Files needed:
−
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
+
* codeblocks.plist (generated, rename to "Info.plist")
−
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
+
* codeblocks.sh (shell wrapper, rename to "CodeBlocks")
−
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon)
+
 
 +
<pre>
 +
#!/bin/sh
 +
 
 +
DIR="`dirname \"$0\"`/.."
 +
 
 +
BIN="$DIR/bin"
 +
LIB="$DIR/lib"
 +
 
 +
DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:$LIB"
 +
export DYLD_LIBRARY_PATH
 +
 
 +
exec "$BIN/codeblocks" --prefix="$DIR"
 +
</pre>
 +
 
 +
* app.icns (icons are available in src/src/resources/icons)
  
 
The MacOS program will just be a shell wrapper that calls "bin/codeblocks", like above.
 
The MacOS program will just be a shell wrapper that calls "bin/codeblocks", like above.
 
Traditionally the bundle would include Frameworks and Resources, but we'll just avoid those
 
Traditionally the bundle would include Frameworks and Resources, but we'll just avoid those
 
here and use the regular "lib" and "share/codeblocks" instead (just as with a regular install).  
 
here and use the regular "lib" and "share/codeblocks" instead (just as with a regular install).  
 +
These temporary directories are listed in italic below, they're not really used in bundles...
  
 
Setup a hierarchy like this, and copy the files from the regular build/install and the above file list to it:
 
Setup a hierarchy like this, and copy the files from the regular build/install and the above file list to it:
Line 275: Line 452:
 
   CodeBlocks.app/Contents/MacOS/CodeBlocks
 
   CodeBlocks.app/Contents/MacOS/CodeBlocks
 
   CodeBlocks.app/Contents/Resources/
 
   CodeBlocks.app/Contents/Resources/
−
   CodeBlocks.app/Contents/Resources/CodeBlocks.icns
+
   CodeBlocks.app/Contents/Resources/app.icns
 
   ''CodeBlocks.app/Contents/bin/''
 
   ''CodeBlocks.app/Contents/bin/''
 
   ''CodeBlocks.app/Contents/lib/''
 
   ''CodeBlocks.app/Contents/lib/''
 
   ''CodeBlocks.app/Contents/share/codeblocks/''
 
   ''CodeBlocks.app/Contents/share/codeblocks/''
  
−
The CodeBlocks application can now be moved with the Finder, and started up like a regular Mac application.
+
The CodeBlocks application can now be moved with the Finder, and started up like a regular Mac application. (the nightly build includes a more advanced Info.plist and more icons - for also mapping all the files that the application can open, like source code and header files and such)
 +
 
 +
==== Proper Application Bundling ====
 +
 
 +
To avoid the shell wrapper, the binary can now be moved from "bin/codeblocks" to "MacOS/CodeBlocks". Helper files are moved from "share/codeblocks" to "Resources". The dynamic libraries are moved from "lib" to "MacOS":
 +
 
 +
<pre>
 +
mv bin/codeblocks MacOS/CodeBlocks
 +
rmdir bin
 +
mv lib/* MacOS/
 +
rmdir lib
 +
mv share Resources/
 +
</pre>
 +
 
 +
To avoid having to use a DYLD_LIBRARY_PATH, we rename the shared libraries (with the install_name_tool program) from e.g. /usr/local/lib/ to @executable_path/:
 +
 
 +
<pre>
 +
install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib \
 +
                          @executable_path/libcodeblocks.0.dylib MacOS/CodeBlocks
 +
</pre>
 +
 
 +
The libraries can have their names changed using the -id parameter:
 +
 
 +
<pre>
 +
install_name_tool -id @executable_path/libcodeblocks.0.dylib MacOS/libcodeblocks.0.dylib
 +
</pre>
 +
 
 +
You also need to change all of the loadable bundles for the plugins:
 +
 
 +
<pre>
 +
for so in Resources/plugins/*.so
 +
do install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib \
 +
                            @executable_path/libcodeblocks.0.dylib $so
 +
done
 +
</pre>
 +
 
 +
You can check the result, what libraries/frameworks it links to, with:
 +
 
 +
<pre>
 +
otool -L CodeBlocks
 +
</pre>
 +
 
 +
Optionally you can then repeat the process, for the wx library too...
 +
 
 +
Here is a full script to do the job... It assumes to be executed at the same directory level as the CodeBlockSVN.app directory that will receive all the stuff... maybe enhanced but it is a first try that do work when packaging an OS X SVN build.
 +
 
 +
<pre>
 +
#!/bin/sh
 +
cp /usr/local/bin/codeblocks ./CodeBlocksSVN.app/Contents/MacOS/CodeBlocks
 +
cp /usr/local/bin/cb_share_config ./CodeBlocksSVN.app/Contents/MacOS
 +
cp /usr/local/bin/cb_console_runner ./CodeBlocksSVN.app/Contents/MacOS
 +
cp /usr/local/bin/codesnippets ./CodeBlocksSVN.app/Contents/MacOS
 +
cp /usr/local/lib/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS
 +
cp /usr/local/lib/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS
 +
cp /usr/local/lib/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS
 +
 
 +
install_name_tool -id @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libcodeblocks.0.dylib
 +
install_name_tool -id @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libwx_macu-2.8.0.dylib
 +
install_name_tool -id @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libwxsmithlib.0.dylib
 +
 
 +
install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/CodeBlocks
 +
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/CodeBlocks
 +
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/CodeBlocks
 +
 
 +
install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/codesnippets
 +
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/codesnippets
 +
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/codesnippets
 +
 
 +
install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_share_config
 +
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_share_config
 +
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_share_config
 +
 
 +
install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_console_runner
 +
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_console_runner
 +
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_console_runner
 +
 
 +
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libcodeblocks.0.dylib
 +
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libcodeblocks.0.dylib
 +
 
 +
install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libwxsmithlib.0.dylib
 +
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libwxsmithlib.0.dylib
 +
 
 +
cp -R /usr/local/share/codeblocks/ ./CodeBlocksSVN.app/Contents/Resources/share/codeblocks
 +
 
 +
for dotso in ./CodeBlocksSVN.app/Contents/Resources/share/codeblocks/plugins/*.so
 +
do
 +
#echo $dotso
 +
# install_name_tool -id $dotso ./libcodeblocks.0.dylib CodeBlocks
 +
install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib $dotso
 +
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib $dotso
 +
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib $dotso
 +
done
 +
</pre>
 +
 
 +
== FYI: Darwin vs. Mac OS X ==
 +
 
 +
"Darwin is the UNIX technology-based foundation of Mac OS X."
 +
 
 +
* http://developer.apple.com/referencelibrary/Darwin/
 +
 
 +
* http://en.wikipedia.org/wiki/Darwin_(operating_system)
 +
 
 +
"Pure Darwin" here refers to the Open Source version of the OS:
 +
 
 +
* http://www.opensource.apple.com/darwinsource/images/
 +
 
 +
* http://puredarwin.org/ or http://gnu-darwin.sourceforge.net/
 +
 
 +
(that is: Darwin using X11 instead of Aqua for the user interface)
 +
 
 +
== Install with MacPorts ==
 +
 
 +
=== Install wxWidgets ===
 +
 
 +
You will need the wxWidgets library, install as port with:
 +
 
 +
<pre>
 +
sudo port install wxWidgets
 +
</pre>
 +
 
 +
If you want the X11/GTK version on Mac OS X, instead use:
 +
 
 +
<pre>
 +
sudo port install wxgtk
 +
</pre>
 +
 
 +
=== Install Code::Blocks ===
 +
 
 +
After that is installed, you can install Code::Blocks with:
 +
 
 +
<pre>
 +
sudo port install codeblocks-devel +aqua
 +
</pre>
 +
 
 +
If you want the X11/GTK version on Mac OS X, instead use:
 +
 
 +
<pre>
 +
sudo port install codeblocks-devel +x11
 +
</pre>
 +
 
 +
This will download the SVN trunk, and any dependencies:
 +
 
 +
<pre>
 +
--->  Fetching codeblocks-devel
 +
--->  Verifying checksum(s) for codeblocks-devel
 +
--->  Extracting codeblocks-devel
 +
--->  Configuring codeblocks-devel
 +
--->  Building codeblocks-devel with target all
 +
--->  Staging codeblocks-devel into destroot
 +
--->  Packaging tgz archive for codeblocks-devel 1.0_0+aqua+macosx
 +
--->  Installing codeblocks-devel 1.0_0+aqua+macosx
 +
--->  Activating codeblocks-devel 1.0_0+aqua+macosx
 +
--->  Cleaning codeblocks-devel
 +
</pre>
 +
 
 +
Note: to upgrade from SVN, you need to uninstall first:
 +
 
 +
<pre>
 +
sudo port uninstall codeblocks-devel
 +
sudo port clean codeblocks-devel
 +
sudo port install codeblocks-devel
 +
</pre>
 +
 
 +
This is both because all SVN versions are numbered "0",
 +
but also due to a bug in the Code::Blocks build scripts.
 +
 
 +
=== Running <tt>+aqua</tt> (wxMac) version ===
 +
 
 +
After the build completes, you can start the program by:
 +
 
 +
<pre>
 +
open /Applications/MacPorts/CodeBlocks.app
 +
</pre>
 +
 
 +
Note that the wxMac application bundle in "MacPorts"
 +
is just a wrapper, with symbolic links to /opt/local...
 +
 
 +
<pre>
 +
/opt/local/bin/codeblocks
 +
</pre>
 +
 
 +
=== Running <tt>+x11</tt> (wxGTK) version ===
 +
 
 +
The non-bundled wxGTK version is instead started with:
 +
 
 +
<pre>
 +
/opt/local/bin/codeblocks
 +
</pre>
 +
 
 +
When running X11/wxGTK programs in Mac OS X, you can use
 +
"open-x11" to first start up X11.app and set up $DISPLAY:
 +
 
 +
<pre>
 +
open-x11 /opt/local/bin/codeblocks
 +
</pre>

Latest revision as of 06:43, 29 August 2010

These are instructions on how to build Code::Blocks under Apple Mac OS X. They have been tested under Mac OS X version 10.4 (PowerPC and Intel), and should work similarly on the newer Mac OS X 10.5 and 10.6 as well.

We will be building everything from scratch using the source code, and not use any available package managers like MacPorts, Fink, Gentoo or RPM. Packaging can be done later, once it has reached a more stable release.

Update: building for MacPorts can be found at the end of the document.

Install Developer Tools

If they didn't come bundled with Mac OS X, get the Xcode Tools (or Developer Tools for older Mac OS X) from http://developer.apple.com/tools/ or from your install disk.

This will install Apple versions of:

Apple regularly pulls all older links in order to promote newer Mac OS X, but all the old developer tools can be downloaded from ADC at http://connect.apple.com/

You need a (free) developer registration with Apple first, in order to log in there. For Mac OS X 10.4, you want (at least) Xcode 2.2, since earlier versions were buggy.

Mac How

Check Autotools versions

Depending on your OS version, you might need to download and compile new versions of these:

Check what you have, with --version (note that GNU libtool is called "glibtool" on Mac OS X)

Currently Code::Blocks requires versions:

  • autoconf 2.50+
  • automake 1.7+ (1.9+ needed in order to build the dist tarball)
  • libtool 1.4+ (1.5.8+ highly recommended to get some bug fixes)

Automake example

For Mac OS X 10.4, you will only need an upgraded (local) installation of automake 1.9.x.

You can download "automake-1.9.6.tar.gz" and configure and install it with something like: 

./configure --prefix=/usr/local --program-suffix=-1.9
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.9/

Since it's now known as "automake-1.9", it won't interfere with the regular "automake"

If you would rather have the new version to be called when calling "automake", let it install into /usr/local and put /usr/local/bin before /usr/bin in your PATH.

Libtool example

Download libtool source. The following instructions will overwrite your current version of libtool with the one you just downloaded. 

cd /libtool-*/
./configure --prefix=/usr --program-prefix=g
make
sudo make install

Note that this will replace the system version of glibtool, which might have some compatibility issues with building other software.

FYI: Universal Binaries

If you are building for Mac OS X 10.4 or later, you might want to build "Universal Binaries " These are binaries that contain code for both PowerPC ("ppc" arch) and Intel ("i386" arch)

The basic flags that needs to be added are: 

CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

(You only need the sysroot parameter on PowerPC Macintosh, not on a Intel Macintosh) The "-arch i386 -arch ppc" is what tells the compiler to build a "universal" (or "fat") binary.

Usually it's easiest to build one version for "powerpc-apple-darwin8", and one version for "i686-apple-darwin8", and then merge them with "lipo" 

./configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8

./configure --host=i686-apple-darwin8 --target=i686-apple-darwin8

Some caveats:

  • pre-compiled headers might fail with a "no main" error. If they do, add a -c to only compile them
  • when cross-compiling, tools like auto_revision might fail to build. copy these from a native build
  • the Tiger compilers might crash from time to time, but that is only to be expected (it seems)...

See Technical Note TN2137: Building Universal Binaries from "configure"-based Open Source Projects

FYI: Compilers

When building for older versions of the SDK, you want to make sure to use the same compiler. 

CC = gcc-4.0

CXX = g++-4.0

Mac OS X 10.6 has GCC 4.2 as the default compiler, which won't work for the Mac OS X 10.4 SDK.

FYI: ANSI or UNICODE

For the moment we are using "ANSI" (--disable-unicode, default) for Mac OS X 10.3 and earlier, and "UNICODE" (--enable-unicode, optional) for Mac OS X 10.4 and later.

See http://www.wxwidgets.org/manuals/stable/wx_unicode.html#unicodeandansi

FYI: 32-bit or 64-bit

Code::Blocks currently uses wxMac (wxOSX/Carbon), which is 32-bit only. So it's not possible to build for "x86_64".

When Code::Blocks (and requirements) has been updated to use wxOSX/Cocoa, then a 64-bit version might be built too.

Build wxWidgets

Download the source code

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/

Apply necessary patches

Don't forget to apply any released patches!

http://wxwidgets.org/downloads/patch.htm

Configure and (GNU) Make

mkdir mac-build
cd mac-build
../configure --enable-shared --enable-monolithic --enable-unicode --with-mac --with-opengl \
            --with-png=builtin --with-jpeg=builtin --with-tiff=builtin --with-expat=builtin
nice make

note: the easiest way to build a Universal Binary with wxWidgets is the new flag: --enable-universal_binary (you need wxWidgets 2.6.4+) 

--enable-universal_binary --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk --with-macosx-version-min=10.4

Install into Destination

sudo make install

Bundle library for Mac

To avoid having the Code::Blocks user having to compile or install wxWidgets themselves, we can bundle it with our application so that it is contained in the application bundle. This could also be done by statically linking wxWidgets, but with dynamic linking we can share the wxWidgets library between all applications using wxWidgets (not just Code::Blocks)


Way One: Library (dynamic)

/usr/local/include/wx-2.8/wx/wx.h
/usr/local/lib/libwx_macu-2.8.dylib -> libwx_macu-2.8.0.dylib
/usr/local/lib/libwx_macu-2.8.0.dylib -> libwx_macu-2.8.0.6.0.dylib
/usr/local/lib/libwx_macu-2.8.0.6.0.dylib

To bundle our shared library with the application, we include it in "MacOS" and change the path: 

install_name_tool -id @executable_path/libwx_macu-2.8.0.dylib

@executable_path will be replaced with e.g. /Developer/Applications/CodeBlocks.app/Contents/MacOS

Way Two: Framework (bundle)

/Library/Frameworks/wx.framework/Headers -> Versions/Current/Headers
/Library/Frameworks/wx.framework/wx -> Versions/Current/wx
/Library/Frameworks/wx.framework/Versions/Current -> 2.8
/Library/Frameworks/wx.framework/Versions/2.8/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.8/wx  -> libwx_macu-2.8.0.dylib
/Library/Frameworks/wx.framework/Versions/2.8/libwx_macu-2.8.0.dylib  -> libwx_macu-2.8.0.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.8/libwx_macu-2.8.0.6.0.dylib

To bundle our framework with the application, we include it in "Frameworks" and change the path: 

install_name_tool -id @executable_path/../Frameworks/wx.framework/Versions/2.8/libwx_macu-2.8.0.dylib

This way it will first look in the framework path (-F), and then in for the shared library path (-L) as usual.

Install Subversion client

On Mac OS X 10.4, you need to install the Subversion (svn) program:

http://subversion.tigris.org/

Note: you need SVN for the Code::Blocks revision scripts to work!

Build CodeBlocks from SVN

Download the source code

https://www.codeblocks.org/source_code.shtml 

svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk

Apply necessary patches

For a list of all available patches, see:

http://developer.berlios.de/patch/?group_id=5358

You might need to convert line endings from DOS to Unix first.

Bootstrap with Autotools

You need to use the newer version of automake (see above), for the "bootstrap". (OS X 10.5 users may have recent enough autotools so they may not need to install them) 

# if you installed newer autotools under names with suffixes.
export AUTOMAKE=automake-1.9
export ACLOCAL=aclocal-1.9

# do bootstrap. you may need to adapt /usr/share/aclocal
# to whatever other location you may use
# (for instance, in my case, /usr/local/share/aclocal)
ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap

Mono Fix

If you have the Mono.framework installed, then it probably set up a symlink like: 

/usr/bin/pkg-config -> /Library/Frameworks/Mono.framework/Commands/pkg-config

Unless you have a "proper" pkg-config installation the Code::Blocks configure will fail, so move this symbolic link aside.

Configure

./configure --with-contrib-plugins=all

Note: the easiest way to build a Universal Binary for Code::Blocks is to build once for PowerPC (-arch ppc) and once for Intel (-arch i386), and then merge them (with lipo) afterwards. 

mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --with-contrib-plugins=all
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --with-contrib-plugins=all
cd ..

Note: You need to patch the location of the pre-compiled headers, or it will generate them in the same place for both arch.

Tiger Fix

There is a bug in the glibtool of Mac OS X 10.4, that fails to link C++ libs: 

ld: multiple definitions of symbol ___umoddi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_umoddi3.o) private external definition of ___umoddi3 in section (__TEXT,__text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_umoddi3_s.o) definition of ___umoddi3

ld: multiple definitions of symbol ___umoddi3
/usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a(_umoddi3.o) private external definition of ___umoddi3 in section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_umoddi3_s.o) definition of ___umoddi3

To work around this, you need to edit the generated "libtool" script manually: 

177c177
< whole_archive_flag_spec="-all_load \$convenience"
---
> whole_archive_flag_spec=""
6921c6921
< whole_archive_flag_spec="-all_load \$convenience"
---
> whole_archive_flag_spec=""

This bug has been fixed in GNU libtool 1.5.8 and later.

(GNU) Make

"nice" isn't strictly needed, it just makes the compile run at a lower process priority 

nice make

For the Universal Binary build: 

cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..

Install into Destination

"sudo" asks you for an admin password, in order to get install permissions 

sudo make install

For the Universal Binary build: 

cd ppc-build
make install DESTDIR=/tmp/ppc
cd ..

cd x86-build
make install DESTDIR=/tmp/x86
cd ..

lipomerge /tmp/ppc /tmp/x86 /tmp/fat

Where "lipomerge" is a custom shell script:

Bundle application for Mac

After building codeblocks in the regular Unix way, you need to bundle it with the icons and various other info that it needs to make a regular stand-alone Macintosh application.

There are two ways of accomplishing this, old Mac OS-style resource or NeXT-style bundle. The old resources are handy while developing, while bundles are more suitable for release.

Note: You need to use either of these methods, or your application will launch in the background behind all other windows and will be unable to receive any events!

Way One: Mac OS (resource)

http://developer.apple.com/documentation/Carbon/Reference/Resource_Manager/

Handy while developing, as you don't need to create a whole bundle.

First we install the program to the PREFIX directory of your choice: 

$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks

Note: on the Intel Macintoshes, the icon comes up as "broken" (apparently it assumes that all apps with resforks are Classic)

Start the application with a small prefix shell wrapper like this: 

DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX

You don't need the "DYLD_LIBRARY_PATH" stuff, if you are installing to a system directory.

Common PREFIX Settings

Local: PREFIX=/usr/local

System: PREFIX=/usr

MacPorts: PREFIX=/opt/local

Fink: PREFIX=/sw

Way Two: NeXT (bundle)

http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/

This does not involve resources, and is more relocatable.

Files needed:

  • codeblocks.plist (generated, rename to "Info.plist")
  • codeblocks.sh (shell wrapper, rename to "CodeBlocks")
#!/bin/sh

DIR="`dirname \"$0\"`/.."

BIN="$DIR/bin"
LIB="$DIR/lib"

DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:$LIB"
export DYLD_LIBRARY_PATH

exec "$BIN/codeblocks" --prefix="$DIR"
  • app.icns (icons are available in src/src/resources/icons)

The MacOS program will just be a shell wrapper that calls "bin/codeblocks", like above. Traditionally the bundle would include Frameworks and Resources, but we'll just avoid those here and use the regular "lib" and "share/codeblocks" instead (just as with a regular install). These temporary directories are listed in italic below, they're not really used in bundles...

Setup a hierarchy like this, and copy the files from the regular build/install and the above file list to it: 

 CodeBlocks.app
 CodeBlocks.app/Contents/
 CodeBlocks.app/Contents/Info.plist
 CodeBlocks.app/Contents/MacOS/
 CodeBlocks.app/Contents/MacOS/CodeBlocks
 CodeBlocks.app/Contents/Resources/
 CodeBlocks.app/Contents/Resources/app.icns
 CodeBlocks.app/Contents/bin/
 CodeBlocks.app/Contents/lib/
 CodeBlocks.app/Contents/share/codeblocks/

The CodeBlocks application can now be moved with the Finder, and started up like a regular Mac application. (the nightly build includes a more advanced Info.plist and more icons - for also mapping all the files that the application can open, like source code and header files and such)

Proper Application Bundling

To avoid the shell wrapper, the binary can now be moved from "bin/codeblocks" to "MacOS/CodeBlocks". Helper files are moved from "share/codeblocks" to "Resources". The dynamic libraries are moved from "lib" to "MacOS": 

mv bin/codeblocks MacOS/CodeBlocks
rmdir bin
mv lib/* MacOS/
rmdir lib
mv share Resources/

To avoid having to use a DYLD_LIBRARY_PATH, we rename the shared libraries (with the install_name_tool program) from e.g. /usr/local/lib/ to @executable_path/: 

install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib \
                          @executable_path/libcodeblocks.0.dylib MacOS/CodeBlocks

The libraries can have their names changed using the -id parameter: 

install_name_tool -id @executable_path/libcodeblocks.0.dylib MacOS/libcodeblocks.0.dylib

You also need to change all of the loadable bundles for the plugins: 

for so in Resources/plugins/*.so
do install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib \
                             @executable_path/libcodeblocks.0.dylib $so
done

You can check the result, what libraries/frameworks it links to, with: 

otool -L CodeBlocks

Optionally you can then repeat the process, for the wx library too...

Here is a full script to do the job... It assumes to be executed at the same directory level as the CodeBlockSVN.app directory that will receive all the stuff... maybe enhanced but it is a first try that do work when packaging an OS X SVN build. 

#!/bin/sh
cp /usr/local/bin/codeblocks ./CodeBlocksSVN.app/Contents/MacOS/CodeBlocks
cp /usr/local/bin/cb_share_config ./CodeBlocksSVN.app/Contents/MacOS
cp /usr/local/bin/cb_console_runner ./CodeBlocksSVN.app/Contents/MacOS
cp /usr/local/bin/codesnippets ./CodeBlocksSVN.app/Contents/MacOS
cp /usr/local/lib/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS
cp /usr/local/lib/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS
cp /usr/local/lib/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS

install_name_tool -id @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libcodeblocks.0.dylib
install_name_tool -id @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libwx_macu-2.8.0.dylib
install_name_tool -id @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libwxsmithlib.0.dylib

install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/CodeBlocks
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/CodeBlocks
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/CodeBlocks

install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/codesnippets
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/codesnippets
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/codesnippets

install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_share_config
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_share_config
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_share_config

install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_console_runner
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_console_runner
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/cb_console_runner

install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libcodeblocks.0.dylib
install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libcodeblocks.0.dylib

install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libwxsmithlib.0.dylib
install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib ./CodeBlocksSVN.app/Contents/MacOS/libwxsmithlib.0.dylib

cp -R /usr/local/share/codeblocks/ ./CodeBlocksSVN.app/Contents/Resources/share/codeblocks

for dotso in ./CodeBlocksSVN.app/Contents/Resources/share/codeblocks/plugins/*.so
do
#echo $dotso
#	install_name_tool -id $dotso ./libcodeblocks.0.dylib CodeBlocks
	install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib @executable_path/libcodeblocks.0.dylib $dotso
	install_name_tool -change /usr/local/lib/libwx_macu-2.8.0.dylib @executable_path/libwx_macu-2.8.0.dylib $dotso
	install_name_tool -change /usr/local/lib/libwxsmithlib.0.dylib @executable_path/libwxsmithlib.0.dylib $dotso
done

FYI: Darwin vs. Mac OS X

"Darwin is the UNIX technology-based foundation of Mac OS X."

"Pure Darwin" here refers to the Open Source version of the OS:

(that is: Darwin using X11 instead of Aqua for the user interface)

Install with MacPorts

Install wxWidgets

You will need the wxWidgets library, install as port with: 

sudo port install wxWidgets

If you want the X11/GTK version on Mac OS X, instead use: 

sudo port install wxgtk

Install Code::Blocks

After that is installed, you can install Code::Blocks with: 

sudo port install codeblocks-devel +aqua

If you want the X11/GTK version on Mac OS X, instead use: 

sudo port install codeblocks-devel +x11

This will download the SVN trunk, and any dependencies: 

--->  Fetching codeblocks-devel
--->  Verifying checksum(s) for codeblocks-devel
--->  Extracting codeblocks-devel
--->  Configuring codeblocks-devel
--->  Building codeblocks-devel with target all
--->  Staging codeblocks-devel into destroot
--->  Packaging tgz archive for codeblocks-devel 1.0_0+aqua+macosx
--->  Installing codeblocks-devel 1.0_0+aqua+macosx
--->  Activating codeblocks-devel 1.0_0+aqua+macosx
--->  Cleaning codeblocks-devel

Note: to upgrade from SVN, you need to uninstall first: 

sudo port uninstall codeblocks-devel
sudo port clean codeblocks-devel
sudo port install codeblocks-devel

This is both because all SVN versions are numbered "0", but also due to a bug in the Code::Blocks build scripts.

Running +aqua (wxMac) version

After the build completes, you can start the program by: 

open /Applications/MacPorts/CodeBlocks.app

Note that the wxMac application bundle in "MacPorts" is just a wrapper, with symbolic links to /opt/local... 

/opt/local/bin/codeblocks

Running +x11 (wxGTK) version

The non-bundled wxGTK version is instead started with: 

/opt/local/bin/codeblocks

When running X11/wxGTK programs in Mac OS X, you can use "open-x11" to first start up X11.app and set up $DISPLAY: 

open-x11 /opt/local/bin/codeblocks
Retrieved from "https://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Mac_OS_X&oldid=6415"