Code::Blocks - User contributions [en]

Main Page

2010-08-28T13:55:59Z

Afb: DMD for all platforms, LDC added

__NOEDITSECTION__ __NOTOC__
{{Layout_box1|1=
[[Image:cb_splash.png|left]]
'''Welcome to the official Wiki for Code::Blocks''' 
[https://www.codeblocks.org Code::Blocks] is an open-source, cross-platform [[wikipedia:Integrated Development Environment|IDE]]. Using a plugin architecture, its capabilities and features are defined by the provided plugins. 
Currently, [https://www.codeblocks.org Code::Blocks] is oriented towards C/C++.
The Code::Blocks team does not take responsibility for the content nor accuracy of these pages.

Wiki Editors: In order to login to edit pages, you must create an account on the [/ forums]. Use the same username and password for the wiki. Read the [[Help:Contents|Help]] for editing guidelines. Look in the [[CodeBlocks:Community_Portal|community portal]] for things to do.

 
}}

{|width="100%" background-color="transparent"
|width="60%" valign="top"|


<div style="background-color: #dfeefb; border: 1px dotted #010101; margin: 5px; padding: 5px;">
{|align="center" style="background:transparent" cellspacing="5"

|valign="top" align="center" colspan="2"|
=== How do I... ===

|-

|align="center"|
'''[[Installing_Code::Blocks|...install Code::Blocks?]]''' 

[[Installing_the_latest_official_version_of_Code::Blocks_on_Windows|Windows]] ·
[[Installing_Code::Blocks#Ubuntu|Ubuntu]] ·
[[Installing_Code::Blocks#Mac_OS_X|Mac OS X]] ·
[[Installing_Code::Blocks#Fedora|Fedora]] ·
[[Installing_Code::Blocks|more...]]


|align="center"|
'''[[Installing_a_supported_compiler|...set up a compiler in Code::Blocks?]]''' 

[[Installing_a_supported_compiler#MinGW.2FGCC|MinGW]] ·
[[Installing_a_supported_compiler#Microsoft_Visual_C.2B.2B|MS Visual C++]] ·
[[Installing_a_supported_compiler|more...]]


|-

|align="center"|
'''...create a new project?''' (Coming soon)

|align="center"|
'''[[Debugging_with_Code::Blocks|...debug my program?]]'''

|-

|align="center"|
'''[[FAQ#Q:_How_do_I_make_Code::Blocks_portable.3F|...make Code::Blocks portable?]]'''

|align="center"|
'''[[User_documentation#Third-party_libraries|...use a 3rd-party library?]]''' 

[[Using_wxWidgets|wxWidgets]] ·
[[Using_Boost|Boost]] ·
[[Using_SDL_with_Code::Blocks|SDL]] ·
[[User_documentation#Third-party_libraries|more...]]


|}
</div>

{{Layout_box3|1=
== Table of Contents ==
''Main article: [[Code::Blocks Documentation]]''

=== [[User documentation]] ===
:Articles for Code::Blocks users

=== [[FAQ]] ===
:Frequently Asked Questions

=== [[Feature List]] ===
:An index of Code::Blocks' useful features

=== [[Code::Blocks Plugins]] ===
:Plugins extend Code::Blocks' functionality

=== [[Off-site documentation]] ===
:Links to external documentation

=== [[Developer documentation]] ===
:Articles for developers of Code::Blocks itself
}}

|width="40%" valign="top"|

{{Layout_box4|1=
=== Download Code::Blocks ===
* Latest official release: [https://www.codeblocks.org/downloads/26 10.05]
* [/index.php?board=20.0 Nightly builds] (updated each night)
* [[Compiled_packages_of_Code::Blocks|Official and third-party binaries]] (for various distributions)
}}

{{Layout_box2|1=
=== Other resources ===
* [https://www.codeblocks.org Main website]
* [ Community forums]
}}

{{Layout_box2|1=
=== Development ===
[[Image:Chk.png]][[Roadmap]]
* [[Developer documentation]]
* [http://developer.berlios.de/projects/codeblocks/ Project page at BerliOS]
* '''Bugs''': [http://developer.berlios.de/bugs/?group_id=5358 Browse] or [http://developer.berlios.de/bugs/?func=addbug&group_id=5358 submit new]
* '''Features''': [http://developer.berlios.de/feature/?group_id=5358 Browse] or [http://developer.berlios.de/feature/?func=addfeature&group_id=5358 submit new]
* '''Patches''': [http://developer.berlios.de/patch/?group_id=5358 Browse] or [http://developer.berlios.de/patch/?func=addpatch&group_id=5358 submit new]
}}

{{Layout_box3|1=
=== Supported compilers ===
* [http://gcc.gnu.org/ GNU GCC (incl. G77)] (Linux)
* [http://www.mingw.org MinGW GCC (incl. G77)] (Win32)
* [http://mspgcc.sourceforge.net MSP430 GCC] (Win32, Linux, BSD)
* [http://www.hightec-rt.com TriCore GCC] (Win32, Linux)
* [http://www.hightec-rt.com PowerPC GCC] (Win32, Linux)
* [http://developer.apple.com/tools/ Apple GCC (Xcode)] (Mac OS X)

* [http://xona.com/2004/06/29.html Microsoft Visual C++ Toolkit 2003] (Win32)
* [http://msdn.microsoft.com/vstudio/express/visualc/download/ Microsoft Visual C++ 2005] (Win32)
* [http://www.borland.com/products/downloads/download_cbuilder.html Borland's C++ Compiler 5.5] (Win32)
* [http://www.digitalmars.com/ DigitalMars C/C++] (Win32)
* [http://openwatcom.org/index.php/Main_Page OpenWatcom] (Win32)
* [http://www.intel.com/cd/software/products/asmo-na/eng/compilers/219754.htm Intel C++ compiler] (Win32)
* [http://sdcc.sourceforge.net/ Small Device C Compiler (SDCC)]
* [http://www.digitalmars.com/d/dcompiler.html Digital Mars D]
* [http://dgcc.sourceforge.net/ GDC D Compiler]
* [http://dsource.org/projects/ldc/ LLVM D Compiler]
}}
|}

<center>[https://www.codeblocks.org/about.shtml The Code::Blocks team]</center>

<center>[[Special:Allpages|Index]]</center>

Installing the latest official version of Code::Blocks on Mac OS X

2010-06-07T06:51:13Z

Afb: /* Install steps */

=== Install steps ===

# [https://www.codeblocks.org/downloads/26#mac Download the Code::Blocks 10.05 image]. If you know you don't have Xcode installed, download the [http://developer.apple.com/tools Developer Tools DVD] from Apple.
# Mount the disk image, it's a standard Apple Disk Image (.dmg). Copy the application to where you want it (e.g. /Developer/Applications).

==== Known Bugs ====

* The "keybinder" plugin is not working in the 10.05 release. Please disable it, or remove <tt>CodeBlocks.app/Contents/Resources/share/codeblocks/libkeybinder.so</tt>

Installing the latest official version of Code::Blocks on Mac OS X

2010-06-05T11:11:28Z

Afb: /* Install steps */

Installing the latest official version of Code::Blocks on Mac OS X

2010-06-05T11:10:06Z

Afb: placeholder

Installing the latest official version of Code::Blocks on Windows

2010-06-05T11:09:57Z

Afb: /* Install steps */ 10.05

[[Category:Installing Code::Blocks]]
[[Category:Installing the latest official version of Code::Blocks]]

=== Install steps ===

# [https://www.codeblocks.org/downloads/26 Download the Code::Blocks 10.05 installer]. If you know you don't have MinGW installed, download the package which has MinGW bundled.
# Run the installer, it's a standard installer for Windows; just press Next after reading each screen.
# If you're planning installing a compiler after you've installed Code::Blocks, read the information provided in the installer.
# If you downloaded the installer which doesn't come with MinGW, you may have to configure the compiler manually (usually Code::Blocks' auto detects the compiler).

Installing Code::Blocks

2010-06-05T11:04:12Z

Afb: /* Mac OS X */

[[Category:Installing Code::Blocks]]

[[Compiled packages of Code::Blocks]]

== MS Windows ==

* [[Installing the latest official version of Code::Blocks on Windows]]
* [[Installing Code::Blocks nightly build on Windows]]
* [[Installing Code::Blocks from source on Windows]]

== Linux ==

* [[Installing Code::Blocks from source on Linux]] (applies to all distros)

=== Ubuntu ===

:* [[Installing Code::Blocks nightly build on Ubuntu]]

=== Debian ===

:* [http://apt.jenslody.de/ Installing Code::Blocks nightly build on Debian]

=== Fedora ===

:* [[Installing Code::Blocks nightly build on Fedora]]

=== Blag ===

:* [[Installing Code::Blocks nightly build on Blag]]

=== Gentoo ===

:* [[Installing Code::Blocks from source on Gentoo]]

=== RPM based distributions ===

Such as: Red Hat Linux, Yellow Dog Linux, Fedora Core, CentOS, etc. etc.

:* [[Installing Code::Blocks nightly build on RPM based distributions]]
:* [[Installing Code::Blocks from source on RPM based distributions]]

== BSD ==

=== FreeBSD ===

:* [[Installing Code::Blocks from source on FreeBSD]]

== Solaris ==

* [[Installing Code::Blocks from source on Solaris]]

== Mac OS X ==

* [[Installing the latest official version of Code::Blocks on Mac OS X]]

* [[Installing Code::Blocks nightly build on Mac OS X]]

* [[Installing Code::Blocks from source on Mac OS X]]

==Working on Code::Blocks sources from within Code::Blocks!==

The following applies for all platforms where you have Code::Blocks installed and working.

After correct install of Code::Blocks you will find two folders under .../trunc/scr , a directory named "devel" and another one named "output".
These two folders will contain the same files and directory structure and you can use the IDE from either of these two directories. This structure has been created so that you can work in Code::Blocks while editing Code::Blocks' sources ;).
Basically, you 'll be using the "output/CodeBlocks.exe" executable. Code::Blocks' project settings are such that all output goes under "devel". So you can edit Code::Blocks' sources inside Code::Blocks and, when pressing "Run", it will run the "devel/CodeBlocks.exe" executable ;). This way, you can't ruin the main executable you 're using (under "output"). When your changes satisfy you and all works well, quit Code::Blocks, run "make update" from command line and re-launch "output/CodeBlocks.exe". You 'll be working on your brand new IDE!

Installing Code::Blocks from source on Mac OS X

2010-06-05T11:01:47Z

Afb: /* Configure */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

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.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 "[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>
./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/
</pre>

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 [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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html 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.

<pre>
CC = gcc-4.0

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

<pre>
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
</pre>

note: the easiest way to build a Universal Binary with wxWidgets is
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 ===

<pre>
sudo make install
</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 ==

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

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

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>
# 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
</pre>

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --with-contrib-plugins=all
</pre>

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.

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

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 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")

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

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

Installing Code::Blocks from source on Mac OS X

2010-06-05T10:59:22Z

Afb: /* FYI: Darwin vs. Mac OS X */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

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.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 "[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>
./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/
</pre>

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 [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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html 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.

<pre>
CC = gcc-4.0

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

<pre>
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
</pre>

note: the easiest way to build a Universal Binary with wxWidgets is
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 ===

<pre>
sudo make install
</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 ==

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

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

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>
# 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
</pre>

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 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")

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

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

Installing Code::Blocks from source on Mac OS X

2010-06-05T10:58:08Z

Afb: /* Way Two: NeXT (bundle) */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

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.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 "[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>
./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/
</pre>

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 [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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html 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.

<pre>
CC = gcc-4.0

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

<pre>
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
</pre>

note: the easiest way to build a Universal Binary with wxWidgets is
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 ===

<pre>
sudo make install
</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 ==

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

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

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>
# 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
</pre>

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 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")

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

<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://opendarwin.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>

Installing Code::Blocks from source on Mac OS X

2010-06-05T10:52:24Z

Afb: /* Way One: Mac OS (resource) */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

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.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 "[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>
./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/
</pre>

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 [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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html 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.

<pre>
CC = gcc-4.0

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

<pre>
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
</pre>

note: the easiest way to build a Universal Binary with wxWidgets is
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 ===

<pre>
sudo make install
</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 ==

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

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

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>
# 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
</pre>

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

<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://opendarwin.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>

Installing Code::Blocks from source on Mac OS X

2010-06-05T10:49:12Z

Afb: /* Install Subversion client */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

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.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 "[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>
./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/
</pre>

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 [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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html 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.

<pre>
CC = gcc-4.0

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

<pre>
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
</pre>

note: the easiest way to build a Universal Binary with wxWidgets is
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 ===

<pre>
sudo make install
</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 ==

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

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

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>
# 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
</pre>

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

<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://opendarwin.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>

Installing Code::Blocks from source on Mac OS X

2010-06-05T10:42:28Z

Afb: compilers and bits

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

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.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 "[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>
./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/
</pre>

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 [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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html 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.

<pre>
CC = gcc-4.0

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

<pre>
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
</pre>

note: the easiest way to build a Universal Binary with wxWidgets is
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 ===

<pre>
sudo make install
</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 ==

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

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

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>
# 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
</pre>

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

<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://opendarwin.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>

Installing Code::Blocks from source on Mac OS X

2010-06-05T10:29:25Z

Afb: /* Bundle library for Mac */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

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.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 "[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>
./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/
</pre>

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 [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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

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

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

<pre>
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
</pre>

note: the easiest way to build a Universal Binary with wxWidgets is
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 ===

<pre>
sudo make install
</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 ==

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

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

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>
# 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
</pre>

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

<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://opendarwin.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>

Installing Code::Blocks from source on Mac OS X

2010-06-05T10:25:10Z

Afb: /* Automake example (Panther) */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

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.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 "[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>
./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/
</pre>

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 [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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

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

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

<pre>
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
</pre>

note: the easiest way to build a Universal Binary with wxWidgets is
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 ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/usr/local/lib/libwx_macu-2.6.0.4.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.4.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.6/libwx_macu-2.6.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 ==

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

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

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>
# 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
</pre>

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

<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://opendarwin.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>

Installing Code::Blocks from source on Mac OS X

2010-06-05T10:21:29Z

Afb: /* Install Developer Tools */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

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.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 [prefix]/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

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 [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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

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

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

<pre>
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
</pre>

note: the easiest way to build a Universal Binary with wxWidgets is
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 ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/usr/local/lib/libwx_macu-2.6.0.4.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.4.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.6/libwx_macu-2.6.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 ==

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

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

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>
# 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
</pre>

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

<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://opendarwin.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>

Installing Code::Blocks from source on Mac OS X

2010-06-05T10:18:36Z

Afb: update supported systems versions

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 [prefix]/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

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 [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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

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

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

<pre>
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
</pre>

note: the easiest way to build a Universal Binary with wxWidgets is
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 ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/usr/local/lib/libwx_macu-2.6.0.4.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.4.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.6/libwx_macu-2.6.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 ==

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

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

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>
# 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
</pre>

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

<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://opendarwin.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>

Installing Code::Blocks from source on Mac OS X

2010-06-05T10:16:04Z

Afb: /* Configure and (GNU) Make */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 [prefix]/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

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 [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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

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

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

<pre>
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
</pre>

note: the easiest way to build a Universal Binary with wxWidgets is
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 ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/usr/local/lib/libwx_macu-2.6.0.4.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.4.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.6/libwx_macu-2.6.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 ==

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

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

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>
# 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
</pre>

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

<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://opendarwin.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>

Installing Code::Blocks nightly build on Mac OS X

2010-06-05T10:09:35Z

Afb: update names/versions

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks nightly build]]
This article describes how to install a nightly build of Code::Blocks.

:''NOTE'': The nightly builds for Mac OS X are not official (just yet)

The packages are currently done infrequently, and not really "nightly".

=== Install steps ===

# Download the Developer Tools from [http://developer.apple.com/tools/ Apple], if not installed with Mac OS X.
#* For Mac OS X 10.4, you need to install Xcode Tools version 2.4 or later
# Download the latest Mac binary ZIP package of Code::Blocks, from [http://developer.berlios.de/project/showfiles.php?group_id=5358 BerliOS].
#* For Mac OS X 10.4 up to 10.6 (PowerPC or Intel), download the "Universal"
# Now unpack the zip file package, and put CodeBlocks.app where you like it.
#* The suggested location is /Developer/Applications or ~/Applications.
#* wxWidgets (2.8.x, dylib) is included inside the application bundle.

=== MacPorts ===

If you prefer, you can install Code::Blocks / wxWidgets using [http://www.macports.org MacPorts] instead:
[[Installing_Code::Blocks_from_source_on_Mac_OS_X#Install_with_MacPorts]].

There are no binary packages for MacPorts just yet, so it compiles from the source.

=== Known Issues ===

First of all, see the issues that apply to all builds of Code::Blocks:

* /index.php?board=20.0 (release notes)
* http://developer.berlios.de/bugs/?group_id=5358 (reported bugs)

There are also some bugs that only apply to the Mac OS X version:

* <s>Open in console doesn't work with Terminal.app, only wxGTK/X11/xterm</s>
* <s>Splash window is not centered on the display</s>
* Occasional "can't flush file descriptor 12"
* Batch building (from the terminal) crashes

Not really bugs, but some things that might require extra setup:
* There is no direct support for adding frameworks, use -framework
* The default package does not have developer files for wxWidgets
* Not all wizards have Mac tweaks to the generated code/projects
* Not all of the included contributed plugins work on Mac just yet

Installing Code::Blocks from source on Mac OS X

2007-08-08T09:14:53Z

Afb: /* Install Code::Blocks */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

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

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

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/usr/local/lib/libwx_macu-2.6.0.4.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.4.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.6/libwx_macu-2.6.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 ==

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

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

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.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>

Installing Code::Blocks from source on Mac OS X

2007-07-15T19:09:19Z

Afb: /* Install Code::Blocks */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

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

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

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/usr/local/lib/libwx_macu-2.6.0.4.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.4.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.6/libwx_macu-2.6.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 ==

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

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

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.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
</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>

Installing Code::Blocks from source on Mac OS X

2007-07-15T18:59:05Z

Afb: update to wxWidgets 2.8 and official MacPorts port

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

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

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

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/usr/local/lib/libwx_macu-2.6.0.4.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.4.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.4.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.6/libwx_macu-2.6.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 ==

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

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

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.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 CB with:

<pre>
sudo port install codeblocks-devel
</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>

Installing Code::Blocks from source on Mac OS X

2007-04-10T22:05:36Z

Afb: DarwinPorts -> MacPorts

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://www.macports.org MacPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

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

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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 Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.org/ or http://gnu-darwin.sourceforge.net/

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

== Install with MacPorts ==

=== Set up a local MacPorts tree ===

Set up a local MacPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as e.g. <tt>dports/devel/codeblocks/Portfile</tt> and download any helper files to e.g. <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

The tree might look something like:
<pre>
dports
|-- PortIndex
`-- devel
`-- codeblocks
`-- Portfile
</pre>

=== Install wxWidgets ===

Currently you need wxWidgets version 2.6.x, install with:

<pre>
sudo port install wxWidgets26
</pre>

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

<pre>
sudo port install wxgk26
</pre>

=== Install Code::Blocks ===

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

After the set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

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

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</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>+puredarwin</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>

Installing Code::Blocks from source on Mac OS X

2007-03-29T12:18:14Z

Afb: /* Install with DarwinPorts */ no more patches

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

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

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.org/ or http://gnu-darwin.sourceforge.net/

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

== Install with DarwinPorts ==

=== Set up a local DarwinPorts tree ===

Set up a local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as e.g. <tt>dports/devel/codeblocks/Portfile</tt> and download any helper files to e.g. <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

The tree might look something like:
<pre>
dports
|-- PortIndex
|-- devel
| `-- codeblocks
| `-- Portfile
`-- graphics
|-- wxGTK
| |-- Portfile
| `-- files
| |-- patch-soundsdl-26.diff
| `-- patch-soundsdl-28.diff
`-- wxMac
`-- Portfile
</pre>

=== Install wxWidgets ===

You will need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl-26.diff
* http://www.algonet.se/~afb/wx/patch-soundsdl-28.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After the set up has been done, you can install it with:

<pre>
sudo port install wxMac
</pre>

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

<pre>
sudo port install wxGTK
</pre>

=== Install Code::Blocks ===

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

After the set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

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

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks
</pre>

=== Running <tt>+puredarwin</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>

Installing Code::Blocks from source on Mac OS X

2007-03-29T08:00:22Z

Afb: /* Install with DarwinPorts */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

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

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.org/ or http://gnu-darwin.sourceforge.net/

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

== Install with DarwinPorts ==

=== Set up a local DarwinPorts tree ===

Set up a local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as e.g. <tt>dports/devel/codeblocks/Portfile</tt> and download any helper files to e.g. <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

The tree might look something like:
<pre>
dports
|-- PortIndex
|-- devel
| `-- codeblocks
| |-- Portfile
| `-- files
| |-- codeblocks.plist
| |-- codeblocks.sh.in
| `-- dos2unix.sh
`-- graphics
|-- wxGTK
| |-- Portfile
| `-- files
| |-- patch-soundsdl-26.diff
| `-- patch-soundsdl-28.diff
`-- wxMac
`-- Portfile
</pre>

=== Install wxWidgets ===

You will need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl-26.diff
* http://www.algonet.se/~afb/wx/patch-soundsdl-28.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After the set up has been done, you can install it with:

<pre>
sudo port install wxMac
</pre>

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

<pre>
sudo port install wxGTK
</pre>

=== Install Code::Blocks ===

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh

After the set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-26T20:23:37Z

Afb: /* Apply necessary patches */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

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

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.org/ or http://gnu-darwin.sourceforge.net/

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

== Install with DarwinPorts ==

=== Set up a local DarwinPorts tree ===

Set up a local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as e.g. <tt>dports/devel/codeblocks/Portfile</tt> and download any helper files to e.g. <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

The tree might look something like:
<pre>
dports
|-- PortIndex
|-- devel
| `-- codeblocks
| |-- Portfile
| `-- files
| |-- codeblocks.plist
| |-- codeblocks.sh.in
| |-- codeblocks-wxauigtk.patch
| |-- codeblocks-darwinplatform.patch
| `-- dos2unix.sh
`-- graphics
|-- wxGTK
| |-- Portfile
| `-- files
| |-- patch-soundsdl-26.diff
| `-- patch-soundsdl-28.diff
`-- wxMac
`-- Portfile
</pre>

=== Install wxWidgets ===

You will need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl-26.diff
* http://www.algonet.se/~afb/wx/patch-soundsdl-28.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After the set up has been done, you can install it with:

<pre>
sudo port install wxMac
</pre>

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

<pre>
sudo port install wxGTK
</pre>

=== Install Code::Blocks ===

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch
* http://www.algonet.se/~afb/wx/codeblocks-darwinplatform.patch

After the set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks nightly build on Mac OS X

2007-03-26T20:18:12Z

Afb: /* Known Issues */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks nightly build]]
This article describes how to install a nightly build of Code::Blocks.

:''NOTE'': The nightly builds for Mac OS X are not official (just yet)

The packages are currently done infrequently, and not really "nightly".

=== Install steps ===

# Download the Developer Tools from [http://developer.apple.com/tools/ Apple], if not included with Mac OS X.
#* For Mac OS X 10.3, you need to install Xcode Tools version 1.2 or later
#* For Mac OS X 10.4, you need to install Xcode Tools version 2.2 or later
# Download the latest Mac binary ZIP package of Code::Blocks, from [http://developer.berlios.de/project/showfiles.php?group_id=5358 BerliOS].
#* For Mac OS X 10.1 up to 10.3 (PPC), download the "macppc" version
#* For Mac OS X 10.4 (PowerPC or Intel), download the "macx86" version
# Now unpack the zip file package, and put CodeBlocks.app where you like it.
#* The suggested location is /Developer/Applications or ~/Applications.
#* wxWidgets (2.6.3p2, dylib) is included inside the application bundle.

=== MacPorts ===

If you prefer, you can install Code::Blocks / wxWidgets using [http://www.macports.org MacPorts] instead:
[[Installing_Code::Blocks_from_source_on_Mac_OS_X#Install_with_DarwinPorts]].

There are no binary packages for MacPorts just yet, so it compiles from the source.

=== Known Issues ===

First of all, see the issues that apply to all builds of Code::Blocks:

* /index.php?board=20.0 (release notes)
* http://developer.berlios.de/bugs/?group_id=5358 (reported bugs)

There are also some bugs that only apply to the Mac OS X version:

* <s>Open in console doesn't work with Terminal.app, only wxGTK/X11/xterm</s>
* <s>Splash window is not centered on the display</s>
* Occasional "can't flush file descriptor 12"
* Batch building (from the terminal) crashes

Not really bugs, but some things that might require extra setup:
* There is no direct support for adding frameworks, use -framework
* The default package does not have developer files for wxWidgets
* Not all wizards have Mac tweaks to the generated code/projects
* Not all of the included contributed plugins work on Mac just yet

Installing Code::Blocks from source on Mac OS X

2007-03-26T11:55:39Z

Afb: /* Install Code::Blocks */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.org/ or http://gnu-darwin.sourceforge.net/

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

== Install with DarwinPorts ==

=== Set up a local DarwinPorts tree ===

Set up a local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as e.g. <tt>dports/devel/codeblocks/Portfile</tt> and download any helper files to e.g. <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

The tree might look something like:
<pre>
dports
|-- PortIndex
|-- devel
| `-- codeblocks
| |-- Portfile
| `-- files
| |-- codeblocks.plist
| |-- codeblocks.sh.in
| |-- codeblocks-wxauigtk.patch
| |-- codeblocks-darwinplatform.patch
| `-- dos2unix.sh
`-- graphics
|-- wxGTK
| |-- Portfile
| `-- files
| |-- patch-soundsdl-26.diff
| `-- patch-soundsdl-28.diff
`-- wxMac
`-- Portfile
</pre>

=== Install wxWidgets ===

You will need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl-26.diff
* http://www.algonet.se/~afb/wx/patch-soundsdl-28.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After the set up has been done, you can install it with:

<pre>
sudo port install wxMac
</pre>

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

<pre>
sudo port install wxGTK
</pre>

=== Install Code::Blocks ===

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch
* http://www.algonet.se/~afb/wx/codeblocks-darwinplatform.patch

After the set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-26T11:55:12Z

Afb: /* Install with DarwinPorts */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.org/ or http://gnu-darwin.sourceforge.net/

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

== Install with DarwinPorts ==

=== Set up a local DarwinPorts tree ===

Set up a local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as e.g. <tt>dports/devel/codeblocks/Portfile</tt> and download any helper files to e.g. <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

The tree might look something like:
<pre>
dports
|-- PortIndex
|-- devel
| `-- codeblocks
| |-- Portfile
| `-- files
| |-- codeblocks.plist
| |-- codeblocks.sh.in
| |-- codeblocks-wxauigtk.patch
| |-- codeblocks-darwinplatform.patch
| `-- dos2unix.sh
`-- graphics
|-- wxGTK
| |-- Portfile
| `-- files
| |-- patch-soundsdl-26.diff
| `-- patch-soundsdl-28.diff
`-- wxMac
`-- Portfile
</pre>

=== Install wxWidgets ===

You will need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl-26.diff
* http://www.algonet.se/~afb/wx/patch-soundsdl-28.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After the set up has been done, you can install it with:

<pre>
sudo port install wxMac
</pre>

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

<pre>
sudo port install wxGTK
</pre>

=== Install Code::Blocks ===

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch
* http://www.algonet.se/~afb/wx/codeblocks-darwinplatform.patch

After the set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-26T11:54:18Z

Afb: /* Set up a local DarwinPorts tree */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.org/ or http://gnu-darwin.sourceforge.net/

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

== Install with DarwinPorts ==

=== Set up a local DarwinPorts tree ===

Set up a local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as e.g. <tt>dports/devel/codeblocks/Portfile</tt> and download any helper files to e.g. <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

The tree might look something like:
<pre>
dports
|-- PortIndex
|-- devel
| `-- codeblocks
| |-- Portfile
| `-- files
| |-- codeblocks.plist
| |-- codeblocks.sh.in
| |-- codeblocks-wxauigtk.patch
| |-- codeblocks-darwinplatform.patch
| `-- dos2unix.sh
`-- graphics
|-- wxGTK
| |-- Portfile
| `-- files
| |-- patch-soundsdl-26.diff
| `-- patch-soundsdl-28.diff
`-- wxMac
`-- Portfile
</pre>

=== Install wxWidgets ===

You will need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After the set up has been done, you can install it with:

<pre>
sudo port install wxMac
</pre>

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

<pre>
sudo port install wxGTK
</pre>

=== Install Code::Blocks ===

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

After the set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on RPM based distributions

2007-03-26T07:57:02Z

Afb: /* Install wxWidgets 2.6.x */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]

== Install Requirements ==

Note: Code::Blocks requires GTK+ 2.x. Older distributions might only support GTK+ 1.x.

Upgrading GTK+ is beyond the scope of this document, easier to upgrade distribution ?

=== Install Development Tools ===

This has to be installed before starting:
* zip
* update-desktop-files (only on SUSE)
* make
* gettext
* autoconf >= 2.5
* automake >= 1.7
* libtool >= 1.4
* m4
* intltool
* gcc-c++
* libstdc++-devel

In Fedora/CentOS, this can be done with:
<pre>
su -c 'yum groupinstall "Development Tools"'
su -c 'yum install intltool'
</pre>

==== Install newer autotools versions (if needed) ====

If you have CentOS 3 or RHEL 3, you will need to rebuild "automake17" to use instead of automake-1.6:
* ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/automake17-1.7.9-5.src.rpm
<pre>
rpmbuild --rebuild automake17-1.7.9-5.src.rpm
</pre>

Then you need to invoke bootstrap like this, both on the commandline and in codeblocks.spec:
<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

=== Setup RPM environment ===

This has to be installed before starting:
* rpm-build

The top work directory for RPM varies between distributions and setups, but you can find your RPM top dir by setting a variable like:

<pre>
RPM_TOPDIR=`rpm --eval %{_topdir}`
echo $RPM_TOPDIR
</pre>

==== Non-root rpmbuild environment (recommended) ====

It is recommended that you don't use the root account to build packages, here is how you set up a minimal user build environment:

<pre>
cd
mkdir rpm
echo "%_topdir $HOME/rpm" >> .rpmmacros
mkdir /tmp/$USER/rpm
echo "%_tmppath /tmp/$USER/rpm" >> .rpmmacros
cd rpm
mkdir SPECS SOURCES BUILD RPMS SRPMS
RPM_TOPDIR=`rpm --eval %{_topdir}`
</pre>

You can now build packages without being root (assuming that the spec files are correct). You will still need root access to install.

=== Install wxWidgets 2.6.x ===

The build requirements in the source RPM are set to a minimum. So it isn't checked whether wxGTK is installed or not. So you have to take a look at it yourself. Note that currently Code::Blocks requires wxWidgets '''2.6''', not 2.8! So if your distribution only provides packages for wxWidgets 2.8, you need to build wxWidgets 2.6 yourself.

This has to be installed:
# wxGTK >= 2.6.0 and its devel package (see [http://wxwidgets.org wxwidgets.org])
# wxGTK-xrc and its devel package (in some distributions included in the packages of point 1)

In later Fedora, this can be done with:
<pre>
su -c 'yum install wxGTK-devel'
</pre>

==== Build the wxGTK RPM from source (if needed) ====

TODO

* http://prdownloads.sourceforge.net/wxwindows/wxGTK-2.6.3.tar.gz
* ftp://biolpc22.york.ac.uk/pub/2.6.3/wxWidgets-2.6.3-Patch-2.tar.gz
* http://www.algonet.se/~afb/wx/wxGTK.spec

RPMS

* wx-base-unicode-2.6.3.0.2-1.i386.rpm
* wx-base-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-gl-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-debuginfo-2.6.3.0.2-1.i386.rpm
* wx-i18n-2.6.3.0.2-1.i386.rpm

=== Install Subversion client ===

This has to be installed before starting:
* subversion >= 1.4.0, (see [http://subversion.tigris.org subversion.tigris.org])

Binary packages for Red Hat Linux 9, Fedora Core 1, CentOS 3, CentOS 4 at:

http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/

In later Fedora, this can be done with:
<pre>
su -c 'yum install subversion'
</pre>

==== Build Subversion RPM from source (if needed) ====

TODO

* http://subversion.tigris.org/downloads/subversion-1.4.2.tar.gz
* packages/rpm/rhel-3/subversion.spec (CentOS 3)
* packages/rpm/rhel-4/subversion.spec (CentOS 4)

RPMS

* subversion-1.4.2-1.i386.rpm
* subversion-devel-1.4.2-1.i386.rpm
* subversion-perl-1.4.2-1.i386.rpm
* subversion-python-1.4.2-1.i386.rpm
* subversion-tools-1.4.2-1.i386.rpm
* subversion-debuginfo-1.4.2-1.i386.rpm

== Install Code::Blocks ==

=== Download the Source RPM ===

1. Download the Source RPM from [https://www.codeblocks.org/downloads.shtml www.codeblocks.org/downloads.shtml]

Note: the SRPM is currently unavailable (latest version being the old RC2), use SVN:

==== Prepare SRPM package from SVN (if needed) ====

1. You need to get the latest sources from SVN [https://www.codeblocks.org/source_code.shtml www.codeblocks.org/source_code.shtml]

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

2. go into ''trunk'', if you haven't already done it.

3. run these three commands in this order
./bootstrap
./configure --enable-contrib
make dist
the last one will create a .tar.gz archive that contains the sources.

4. copy the archive to the directory $RPM_TOPDIR/SOURCES
sudo mv codeblocks-trunk-r*.tar.gz $RPM_TOPDIR/SOURCES

5. build the source RPM, or copy spec to $RPM_TOPDIR/SPECS
rpmbuild -bs codeblocks.spec

This will create a source package in the directory $RPM_TOPDIR/SRPMS/.

=== Build the RPM package ===

1. Build the binary package
rpmbuild --rebuild codeblocks-1.0*.src.rpm

This will create several packages in one of the architecture specific subdirectories (i386, x86_64, ppc, ...) of $RPM_TOPDIR/RPMS/.

These are:
* codeblocks: main package
* codeblocks-contrib: contrib plugins
* codeblocks-devel: SDK headers
* codeblocks-debuginfo: stripped debug information

=== Install the RPM package ===

Install as root the packages you want (usually codeblocks and codeblocks-contrib) and enjoy Code::Blocks!
su -c 'rpm -Uvh codeblocks-1.0*.i386.rpm'

Installing Code::Blocks from source on RPM based distributions

2007-03-26T07:55:30Z

Afb: /* Install the RPM package */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]

== Install Requirements ==

Note: Code::Blocks requires GTK+ 2.x. Older distributions might only support GTK+ 1.x.

Upgrading GTK+ is beyond the scope of this document, easier to upgrade distribution ?

=== Install Development Tools ===

This has to be installed before starting:
* zip
* update-desktop-files (only on SUSE)
* make
* gettext
* autoconf >= 2.5
* automake >= 1.7
* libtool >= 1.4
* m4
* intltool
* gcc-c++
* libstdc++-devel

In Fedora/CentOS, this can be done with:
<pre>
su -c 'yum groupinstall "Development Tools"'
su -c 'yum install intltool'
</pre>

==== Install newer autotools versions (if needed) ====

If you have CentOS 3 or RHEL 3, you will need to rebuild "automake17" to use instead of automake-1.6:
* ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/automake17-1.7.9-5.src.rpm
<pre>
rpmbuild --rebuild automake17-1.7.9-5.src.rpm
</pre>

Then you need to invoke bootstrap like this, both on the commandline and in codeblocks.spec:
<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

=== Setup RPM environment ===

This has to be installed before starting:
* rpm-build

The top work directory for RPM varies between distributions and setups, but you can find your RPM top dir by setting a variable like:

<pre>
RPM_TOPDIR=`rpm --eval %{_topdir}`
echo $RPM_TOPDIR
</pre>

==== Non-root rpmbuild environment (recommended) ====

It is recommended that you don't use the root account to build packages, here is how you set up a minimal user build environment:

<pre>
cd
mkdir rpm
echo "%_topdir $HOME/rpm" >> .rpmmacros
mkdir /tmp/$USER/rpm
echo "%_tmppath /tmp/$USER/rpm" >> .rpmmacros
cd rpm
mkdir SPECS SOURCES BUILD RPMS SRPMS
RPM_TOPDIR=`rpm --eval %{_topdir}`
</pre>

You can now build packages without being root (assuming that the spec files are correct). You will still need root access to install.

=== Install wxWidgets 2.6.x ===

The build requirements in the source RPM are set to a minimum. So it isn't checked whether wxGTK is installed or not. So you have to take a look at it yourself.

This has to be installed:
# wxGTK >= 2.6.0 and its devel package (see [http://wxwidgets.org wxwidgets.org])
# wxGTK-xrc and its devel package (in some distributions included in the packages of point 1)

In later Fedora, this can be done with:
<pre>
su -c 'yum install wxGTK-devel'
</pre>

==== Build the wxGTK RPM from source (if needed) ====

TODO

* http://prdownloads.sourceforge.net/wxwindows/wxGTK-2.6.3.tar.gz
* ftp://biolpc22.york.ac.uk/pub/2.6.3/wxWidgets-2.6.3-Patch-2.tar.gz
* http://www.algonet.se/~afb/wx/wxGTK.spec

RPMS

* wx-base-unicode-2.6.3.0.2-1.i386.rpm
* wx-base-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-gl-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-debuginfo-2.6.3.0.2-1.i386.rpm
* wx-i18n-2.6.3.0.2-1.i386.rpm

=== Install Subversion client ===

This has to be installed before starting:
* subversion >= 1.4.0, (see [http://subversion.tigris.org subversion.tigris.org])

Binary packages for Red Hat Linux 9, Fedora Core 1, CentOS 3, CentOS 4 at:

http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/

In later Fedora, this can be done with:
<pre>
su -c 'yum install subversion'
</pre>

==== Build Subversion RPM from source (if needed) ====

TODO

* http://subversion.tigris.org/downloads/subversion-1.4.2.tar.gz
* packages/rpm/rhel-3/subversion.spec (CentOS 3)
* packages/rpm/rhel-4/subversion.spec (CentOS 4)

RPMS

* subversion-1.4.2-1.i386.rpm
* subversion-devel-1.4.2-1.i386.rpm
* subversion-perl-1.4.2-1.i386.rpm
* subversion-python-1.4.2-1.i386.rpm
* subversion-tools-1.4.2-1.i386.rpm
* subversion-debuginfo-1.4.2-1.i386.rpm

== Install Code::Blocks ==

=== Download the Source RPM ===

1. Download the Source RPM from [https://www.codeblocks.org/downloads.shtml www.codeblocks.org/downloads.shtml]

Note: the SRPM is currently unavailable (latest version being the old RC2), use SVN:

==== Prepare SRPM package from SVN (if needed) ====

1. You need to get the latest sources from SVN [https://www.codeblocks.org/source_code.shtml www.codeblocks.org/source_code.shtml]

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

2. go into ''trunk'', if you haven't already done it.

3. run these three commands in this order
./bootstrap
./configure --enable-contrib
make dist
the last one will create a .tar.gz archive that contains the sources.

4. copy the archive to the directory $RPM_TOPDIR/SOURCES
sudo mv codeblocks-trunk-r*.tar.gz $RPM_TOPDIR/SOURCES

5. build the source RPM, or copy spec to $RPM_TOPDIR/SPECS
rpmbuild -bs codeblocks.spec

This will create a source package in the directory $RPM_TOPDIR/SRPMS/.

=== Build the RPM package ===

1. Build the binary package
rpmbuild --rebuild codeblocks-1.0*.src.rpm

This will create several packages in one of the architecture specific subdirectories (i386, x86_64, ppc, ...) of $RPM_TOPDIR/RPMS/.

These are:
* codeblocks: main package
* codeblocks-contrib: contrib plugins
* codeblocks-devel: SDK headers
* codeblocks-debuginfo: stripped debug information

=== Install the RPM package ===

Install as root the packages you want (usually codeblocks and codeblocks-contrib) and enjoy Code::Blocks!
su -c 'rpm -Uvh codeblocks-1.0*.i386.rpm'

Installing Code::Blocks from source on RPM based distributions

2007-03-26T07:54:38Z

Afb: /* Install Requirements */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]

== Install Requirements ==

Note: Code::Blocks requires GTK+ 2.x. Older distributions might only support GTK+ 1.x.

Upgrading GTK+ is beyond the scope of this document, easier to upgrade distribution ?

=== Install Development Tools ===

This has to be installed before starting:
* zip
* update-desktop-files (only on SUSE)
* make
* gettext
* autoconf >= 2.5
* automake >= 1.7
* libtool >= 1.4
* m4
* intltool
* gcc-c++
* libstdc++-devel

In Fedora/CentOS, this can be done with:
<pre>
su -c 'yum groupinstall "Development Tools"'
su -c 'yum install intltool'
</pre>

==== Install newer autotools versions (if needed) ====

If you have CentOS 3 or RHEL 3, you will need to rebuild "automake17" to use instead of automake-1.6:
* ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/automake17-1.7.9-5.src.rpm
<pre>
rpmbuild --rebuild automake17-1.7.9-5.src.rpm
</pre>

Then you need to invoke bootstrap like this, both on the commandline and in codeblocks.spec:
<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

=== Setup RPM environment ===

This has to be installed before starting:
* rpm-build

The top work directory for RPM varies between distributions and setups, but you can find your RPM top dir by setting a variable like:

<pre>
RPM_TOPDIR=`rpm --eval %{_topdir}`
echo $RPM_TOPDIR
</pre>

==== Non-root rpmbuild environment (recommended) ====

It is recommended that you don't use the root account to build packages, here is how you set up a minimal user build environment:

<pre>
cd
mkdir rpm
echo "%_topdir $HOME/rpm" >> .rpmmacros
mkdir /tmp/$USER/rpm
echo "%_tmppath /tmp/$USER/rpm" >> .rpmmacros
cd rpm
mkdir SPECS SOURCES BUILD RPMS SRPMS
RPM_TOPDIR=`rpm --eval %{_topdir}`
</pre>

You can now build packages without being root (assuming that the spec files are correct). You will still need root access to install.

=== Install wxWidgets 2.6.x ===

The build requirements in the source RPM are set to a minimum. So it isn't checked whether wxGTK is installed or not. So you have to take a look at it yourself.

This has to be installed:
# wxGTK >= 2.6.0 and its devel package (see [http://wxwidgets.org wxwidgets.org])
# wxGTK-xrc and its devel package (in some distributions included in the packages of point 1)

In later Fedora, this can be done with:
<pre>
su -c 'yum install wxGTK-devel'
</pre>

==== Build the wxGTK RPM from source (if needed) ====

TODO

* http://prdownloads.sourceforge.net/wxwindows/wxGTK-2.6.3.tar.gz
* ftp://biolpc22.york.ac.uk/pub/2.6.3/wxWidgets-2.6.3-Patch-2.tar.gz
* http://www.algonet.se/~afb/wx/wxGTK.spec

RPMS

* wx-base-unicode-2.6.3.0.2-1.i386.rpm
* wx-base-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-gl-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-debuginfo-2.6.3.0.2-1.i386.rpm
* wx-i18n-2.6.3.0.2-1.i386.rpm

=== Install Subversion client ===

This has to be installed before starting:
* subversion >= 1.4.0, (see [http://subversion.tigris.org subversion.tigris.org])

Binary packages for Red Hat Linux 9, Fedora Core 1, CentOS 3, CentOS 4 at:

http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/

In later Fedora, this can be done with:
<pre>
su -c 'yum install subversion'
</pre>

==== Build Subversion RPM from source (if needed) ====

TODO

* http://subversion.tigris.org/downloads/subversion-1.4.2.tar.gz
* packages/rpm/rhel-3/subversion.spec (CentOS 3)
* packages/rpm/rhel-4/subversion.spec (CentOS 4)

RPMS

* subversion-1.4.2-1.i386.rpm
* subversion-devel-1.4.2-1.i386.rpm
* subversion-perl-1.4.2-1.i386.rpm
* subversion-python-1.4.2-1.i386.rpm
* subversion-tools-1.4.2-1.i386.rpm
* subversion-debuginfo-1.4.2-1.i386.rpm

== Install Code::Blocks ==

=== Download the Source RPM ===

1. Download the Source RPM from [https://www.codeblocks.org/downloads.shtml www.codeblocks.org/downloads.shtml]

Note: the SRPM is currently unavailable (latest version being the old RC2), use SVN:

==== Prepare SRPM package from SVN (if needed) ====

1. You need to get the latest sources from SVN [https://www.codeblocks.org/source_code.shtml www.codeblocks.org/source_code.shtml]

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

2. go into ''trunk'', if you haven't already done it.

3. run these three commands in this order
./bootstrap
./configure --enable-contrib
make dist
the last one will create a .tar.gz archive that contains the sources.

4. copy the archive to the directory $RPM_TOPDIR/SOURCES
sudo mv codeblocks-trunk-r*.tar.gz $RPM_TOPDIR/SOURCES

5. build the source RPM, or copy spec to $RPM_TOPDIR/SPECS
rpmbuild -bs codeblocks.spec

This will create a source package in the directory $RPM_TOPDIR/SRPMS/.

=== Build the RPM package ===

1. Build the binary package
rpmbuild --rebuild codeblocks-1.0*.src.rpm

This will create several packages in one of the architecture specific subdirectories (i386, x86_64, ppc, ...) of $RPM_TOPDIR/RPMS/.

These are:
* codeblocks: main package
* codeblocks-contrib: contrib plugins
* codeblocks-devel: SDK headers
* codeblocks-debuginfo: stripped debug information

=== Install the RPM package ===

Install as root the packages you want (usually codeblocks and codeblocks-contrib) and enjoy Code::Blocks!
sudo rpm -Uvh codeblocks-1.0*.i386.rpm

Installing Code::Blocks from source on RPM based distributions

2007-03-26T07:53:13Z

Afb: /* Install the RPM package */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]

== Install Requirements ==

Note: Code::Blocks requires GTK+ 2.x. Older distributions might only support GTK+ 1.x.

=== Install Development Tools ===

This has to be installed before starting:
* zip
* update-desktop-files (only on SUSE)
* make
* gettext
* autoconf >= 2.5
* automake >= 1.7
* libtool >= 1.4
* m4
* intltool
* gcc-c++
* libstdc++-devel

In Fedora/CentOS, this can be done with:
<pre>
su -c 'yum groupinstall "Development Tools"'
su -c 'yum install intltool'
</pre>

==== Install newer autotools versions (if needed) ====

If you have CentOS 3 or RHEL 3, you will need to rebuild "automake17" to use instead of automake-1.6:
* ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/automake17-1.7.9-5.src.rpm
<pre>
rpmbuild --rebuild automake17-1.7.9-5.src.rpm
</pre>

Then you need to invoke bootstrap like this, both on the commandline and in codeblocks.spec:
<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

=== Setup RPM environment ===

This has to be installed before starting:
* rpm-build

The top work directory for RPM varies between distributions and setups, but you can find your RPM top dir by setting a variable like:

<pre>
RPM_TOPDIR=`rpm --eval %{_topdir}`
echo $RPM_TOPDIR
</pre>

==== Non-root rpmbuild environment (recommended) ====

It is recommended that you don't use the root account to build packages, here is how you set up a minimal user build environment:

<pre>
cd
mkdir rpm
echo "%_topdir $HOME/rpm" >> .rpmmacros
mkdir /tmp/$USER/rpm
echo "%_tmppath /tmp/$USER/rpm" >> .rpmmacros
cd rpm
mkdir SPECS SOURCES BUILD RPMS SRPMS
RPM_TOPDIR=`rpm --eval %{_topdir}`
</pre>

You can now build packages without being root (assuming that the spec files are correct). You will still need root access to install.

=== Install wxWidgets 2.6.x ===

The build requirements in the source RPM are set to a minimum. So it isn't checked whether wxGTK is installed or not. So you have to take a look at it yourself.

This has to be installed:
# wxGTK >= 2.6.0 and its devel package (see [http://wxwidgets.org wxwidgets.org])
# wxGTK-xrc and its devel package (in some distributions included in the packages of point 1)

In later Fedora, this can be done with:
<pre>
su -c 'yum install wxGTK-devel'
</pre>

==== Build the wxGTK RPM from source (if needed) ====

TODO

* http://prdownloads.sourceforge.net/wxwindows/wxGTK-2.6.3.tar.gz
* ftp://biolpc22.york.ac.uk/pub/2.6.3/wxWidgets-2.6.3-Patch-2.tar.gz
* http://www.algonet.se/~afb/wx/wxGTK.spec

RPMS

* wx-base-unicode-2.6.3.0.2-1.i386.rpm
* wx-base-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-gl-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-debuginfo-2.6.3.0.2-1.i386.rpm
* wx-i18n-2.6.3.0.2-1.i386.rpm

=== Install Subversion client ===

This has to be installed before starting:
* subversion >= 1.4.0, (see [http://subversion.tigris.org subversion.tigris.org])

Binary packages for Red Hat Linux 9, Fedora Core 1, CentOS 3, CentOS 4 at:

http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/

In later Fedora, this can be done with:
<pre>
su -c 'yum install subversion'
</pre>

==== Build Subversion RPM from source (if needed) ====

TODO

* http://subversion.tigris.org/downloads/subversion-1.4.2.tar.gz
* packages/rpm/rhel-3/subversion.spec (CentOS 3)
* packages/rpm/rhel-4/subversion.spec (CentOS 4)

RPMS

* subversion-1.4.2-1.i386.rpm
* subversion-devel-1.4.2-1.i386.rpm
* subversion-perl-1.4.2-1.i386.rpm
* subversion-python-1.4.2-1.i386.rpm
* subversion-tools-1.4.2-1.i386.rpm
* subversion-debuginfo-1.4.2-1.i386.rpm

== Install Code::Blocks ==

=== Download the Source RPM ===

1. Download the Source RPM from [https://www.codeblocks.org/downloads.shtml www.codeblocks.org/downloads.shtml]

Note: the SRPM is currently unavailable (latest version being the old RC2), use SVN:

==== Prepare SRPM package from SVN (if needed) ====

1. You need to get the latest sources from SVN [https://www.codeblocks.org/source_code.shtml www.codeblocks.org/source_code.shtml]

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

2. go into ''trunk'', if you haven't already done it.

3. run these three commands in this order
./bootstrap
./configure --enable-contrib
make dist
the last one will create a .tar.gz archive that contains the sources.

4. copy the archive to the directory $RPM_TOPDIR/SOURCES
sudo mv codeblocks-trunk-r*.tar.gz $RPM_TOPDIR/SOURCES

5. build the source RPM, or copy spec to $RPM_TOPDIR/SPECS
rpmbuild -bs codeblocks.spec

This will create a source package in the directory $RPM_TOPDIR/SRPMS/.

=== Build the RPM package ===

1. Build the binary package
rpmbuild --rebuild codeblocks-1.0*.src.rpm

This will create several packages in one of the architecture specific subdirectories (i386, x86_64, ppc, ...) of $RPM_TOPDIR/RPMS/.

These are:
* codeblocks: main package
* codeblocks-contrib: contrib plugins
* codeblocks-devel: SDK headers
* codeblocks-debuginfo: stripped debug information

=== Install the RPM package ===

Install as root the packages you want (usually codeblocks and codeblocks-contrib) and enjoy Code::Blocks!
sudo rpm -Uvh codeblocks-1.0*.i386.rpm

Installing Code::Blocks from source on RPM based distributions

2007-03-26T07:51:31Z

Afb: /* Prepare SRPM package from SVN (if needed) */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]

== Install Requirements ==

Note: Code::Blocks requires GTK+ 2.x. Older distributions might only support GTK+ 1.x.

=== Install Development Tools ===

This has to be installed before starting:
* zip
* update-desktop-files (only on SUSE)
* make
* gettext
* autoconf >= 2.5
* automake >= 1.7
* libtool >= 1.4
* m4
* intltool
* gcc-c++
* libstdc++-devel

In Fedora/CentOS, this can be done with:
<pre>
su -c 'yum groupinstall "Development Tools"'
su -c 'yum install intltool'
</pre>

==== Install newer autotools versions (if needed) ====

If you have CentOS 3 or RHEL 3, you will need to rebuild "automake17" to use instead of automake-1.6:
* ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/automake17-1.7.9-5.src.rpm
<pre>
rpmbuild --rebuild automake17-1.7.9-5.src.rpm
</pre>

Then you need to invoke bootstrap like this, both on the commandline and in codeblocks.spec:
<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

=== Setup RPM environment ===

This has to be installed before starting:
* rpm-build

The top work directory for RPM varies between distributions and setups, but you can find your RPM top dir by setting a variable like:

<pre>
RPM_TOPDIR=`rpm --eval %{_topdir}`
echo $RPM_TOPDIR
</pre>

==== Non-root rpmbuild environment (recommended) ====

It is recommended that you don't use the root account to build packages, here is how you set up a minimal user build environment:

<pre>
cd
mkdir rpm
echo "%_topdir $HOME/rpm" >> .rpmmacros
mkdir /tmp/$USER/rpm
echo "%_tmppath /tmp/$USER/rpm" >> .rpmmacros
cd rpm
mkdir SPECS SOURCES BUILD RPMS SRPMS
RPM_TOPDIR=`rpm --eval %{_topdir}`
</pre>

You can now build packages without being root (assuming that the spec files are correct). You will still need root access to install.

=== Install wxWidgets 2.6.x ===

The build requirements in the source RPM are set to a minimum. So it isn't checked whether wxGTK is installed or not. So you have to take a look at it yourself.

This has to be installed:
# wxGTK >= 2.6.0 and its devel package (see [http://wxwidgets.org wxwidgets.org])
# wxGTK-xrc and its devel package (in some distributions included in the packages of point 1)

In later Fedora, this can be done with:
<pre>
su -c 'yum install wxGTK-devel'
</pre>

==== Build the wxGTK RPM from source (if needed) ====

TODO

* http://prdownloads.sourceforge.net/wxwindows/wxGTK-2.6.3.tar.gz
* ftp://biolpc22.york.ac.uk/pub/2.6.3/wxWidgets-2.6.3-Patch-2.tar.gz
* http://www.algonet.se/~afb/wx/wxGTK.spec

RPMS

* wx-base-unicode-2.6.3.0.2-1.i386.rpm
* wx-base-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-gl-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-debuginfo-2.6.3.0.2-1.i386.rpm
* wx-i18n-2.6.3.0.2-1.i386.rpm

=== Install Subversion client ===

This has to be installed before starting:
* subversion >= 1.4.0, (see [http://subversion.tigris.org subversion.tigris.org])

Binary packages for Red Hat Linux 9, Fedora Core 1, CentOS 3, CentOS 4 at:

http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/

In later Fedora, this can be done with:
<pre>
su -c 'yum install subversion'
</pre>

==== Build Subversion RPM from source (if needed) ====

TODO

* http://subversion.tigris.org/downloads/subversion-1.4.2.tar.gz
* packages/rpm/rhel-3/subversion.spec (CentOS 3)
* packages/rpm/rhel-4/subversion.spec (CentOS 4)

RPMS

* subversion-1.4.2-1.i386.rpm
* subversion-devel-1.4.2-1.i386.rpm
* subversion-perl-1.4.2-1.i386.rpm
* subversion-python-1.4.2-1.i386.rpm
* subversion-tools-1.4.2-1.i386.rpm
* subversion-debuginfo-1.4.2-1.i386.rpm

== Install Code::Blocks ==

=== Download the Source RPM ===

1. Download the Source RPM from [https://www.codeblocks.org/downloads.shtml www.codeblocks.org/downloads.shtml]

Note: the SRPM is currently unavailable (latest version being the old RC2), use SVN:

==== Prepare SRPM package from SVN (if needed) ====

1. You need to get the latest sources from SVN [https://www.codeblocks.org/source_code.shtml www.codeblocks.org/source_code.shtml]

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

2. go into ''trunk'', if you haven't already done it.

3. run these three commands in this order
./bootstrap
./configure --enable-contrib
make dist
the last one will create a .tar.gz archive that contains the sources.

4. copy the archive to the directory $RPM_TOPDIR/SOURCES
sudo mv codeblocks-trunk-r*.tar.gz $RPM_TOPDIR/SOURCES

5. build the source RPM, or copy spec to $RPM_TOPDIR/SPECS
rpmbuild -bs codeblocks.spec

This will create a source package in the directory $RPM_TOPDIR/SRPMS/.

=== Build the RPM package ===

1. Build the binary package
rpmbuild --rebuild codeblocks-1.0*.src.rpm

This will create several packages in one of the architecture specific subdirectories (i386, x86_64, ppc, ...) of $RPM_TOPDIR/RPMS/.

These are:
* codeblocks: main package
* codeblocks-contrib: contrib plugins
* codeblocks-devel: SDK headers
* codeblocks-debuginfo: stripped debug information

=== Install the RPM package ===

Install as root the packages you want (usually codeblocks and codeblocks-contrib) and enjoy Code::Blocks!

Installing Code::Blocks from source on RPM based distributions

2007-03-26T07:50:50Z

Afb: /* Install Code::Blocks */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]

== Install Requirements ==

Note: Code::Blocks requires GTK+ 2.x. Older distributions might only support GTK+ 1.x.

=== Install Development Tools ===

This has to be installed before starting:
* zip
* update-desktop-files (only on SUSE)
* make
* gettext
* autoconf >= 2.5
* automake >= 1.7
* libtool >= 1.4
* m4
* intltool
* gcc-c++
* libstdc++-devel

In Fedora/CentOS, this can be done with:
<pre>
su -c 'yum groupinstall "Development Tools"'
su -c 'yum install intltool'
</pre>

==== Install newer autotools versions (if needed) ====

If you have CentOS 3 or RHEL 3, you will need to rebuild "automake17" to use instead of automake-1.6:
* ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/automake17-1.7.9-5.src.rpm
<pre>
rpmbuild --rebuild automake17-1.7.9-5.src.rpm
</pre>

Then you need to invoke bootstrap like this, both on the commandline and in codeblocks.spec:
<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

=== Setup RPM environment ===

This has to be installed before starting:
* rpm-build

The top work directory for RPM varies between distributions and setups, but you can find your RPM top dir by setting a variable like:

<pre>
RPM_TOPDIR=`rpm --eval %{_topdir}`
echo $RPM_TOPDIR
</pre>

==== Non-root rpmbuild environment (recommended) ====

It is recommended that you don't use the root account to build packages, here is how you set up a minimal user build environment:

<pre>
cd
mkdir rpm
echo "%_topdir $HOME/rpm" >> .rpmmacros
mkdir /tmp/$USER/rpm
echo "%_tmppath /tmp/$USER/rpm" >> .rpmmacros
cd rpm
mkdir SPECS SOURCES BUILD RPMS SRPMS
RPM_TOPDIR=`rpm --eval %{_topdir}`
</pre>

You can now build packages without being root (assuming that the spec files are correct). You will still need root access to install.

=== Install wxWidgets 2.6.x ===

The build requirements in the source RPM are set to a minimum. So it isn't checked whether wxGTK is installed or not. So you have to take a look at it yourself.

This has to be installed:
# wxGTK >= 2.6.0 and its devel package (see [http://wxwidgets.org wxwidgets.org])
# wxGTK-xrc and its devel package (in some distributions included in the packages of point 1)

In later Fedora, this can be done with:
<pre>
su -c 'yum install wxGTK-devel'
</pre>

==== Build the wxGTK RPM from source (if needed) ====

TODO

* http://prdownloads.sourceforge.net/wxwindows/wxGTK-2.6.3.tar.gz
* ftp://biolpc22.york.ac.uk/pub/2.6.3/wxWidgets-2.6.3-Patch-2.tar.gz
* http://www.algonet.se/~afb/wx/wxGTK.spec

RPMS

* wx-base-unicode-2.6.3.0.2-1.i386.rpm
* wx-base-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-gl-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-debuginfo-2.6.3.0.2-1.i386.rpm
* wx-i18n-2.6.3.0.2-1.i386.rpm

=== Install Subversion client ===

This has to be installed before starting:
* subversion >= 1.4.0, (see [http://subversion.tigris.org subversion.tigris.org])

Binary packages for Red Hat Linux 9, Fedora Core 1, CentOS 3, CentOS 4 at:

http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/

In later Fedora, this can be done with:
<pre>
su -c 'yum install subversion'
</pre>

==== Build Subversion RPM from source (if needed) ====

TODO

* http://subversion.tigris.org/downloads/subversion-1.4.2.tar.gz
* packages/rpm/rhel-3/subversion.spec (CentOS 3)
* packages/rpm/rhel-4/subversion.spec (CentOS 4)

RPMS

* subversion-1.4.2-1.i386.rpm
* subversion-devel-1.4.2-1.i386.rpm
* subversion-perl-1.4.2-1.i386.rpm
* subversion-python-1.4.2-1.i386.rpm
* subversion-tools-1.4.2-1.i386.rpm
* subversion-debuginfo-1.4.2-1.i386.rpm

== Install Code::Blocks ==

=== Download the Source RPM ===

1. Download the Source RPM from [https://www.codeblocks.org/downloads.shtml www.codeblocks.org/downloads.shtml]

Note: the SRPM is currently unavailable (latest version being the old RC2), use SVN:

==== Prepare SRPM package from SVN (if needed) ====

1. You need to get the latest sources from SVN [https://www.codeblocks.org/source_code.shtml www.codeblocks.org/source_code.shtml]

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

2. go into ''trunk'', if you haven't already done it.

3. run these three commands in this order
./bootstrap
./configure --enable-contrib
make dist
the last one will create a .tar.gz archive that contains the sources.

4. copy the archive to the directory $RPM_TOPDIR/SOURCES
sudo mv codeblocks-trunk-r$REVISION.tar.gz $RPM_TOPDIR/SOURCES

5. build the source RPM, or copy spec to $RPM_TOPDIR/SPECS
rpmbuild -bs codeblocks.spec

This will create a source package in the directory $RPM_TOPDIR/SRPMS/.

=== Build the RPM package ===

1. Build the binary package
rpmbuild --rebuild codeblocks-1.0*.src.rpm

This will create several packages in one of the architecture specific subdirectories (i386, x86_64, ppc, ...) of $RPM_TOPDIR/RPMS/.

These are:
* codeblocks: main package
* codeblocks-contrib: contrib plugins
* codeblocks-devel: SDK headers
* codeblocks-debuginfo: stripped debug information

=== Install the RPM package ===

Install as root the packages you want (usually codeblocks and codeblocks-contrib) and enjoy Code::Blocks!

Installing Code::Blocks from source on Mac OS X

2007-03-22T10:57:10Z

Afb: /* Install with DarwinPorts */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.org/ or http://gnu-darwin.sourceforge.net/

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

== Install with DarwinPorts ==

=== Set up a local DarwinPorts tree ===

Set up a local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as e.g. <tt>dports/devel/codeblocks/Portfile</tt> and download any helper files to e.g. <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

The tree might look something like:
<pre>
dports
|-- PortIndex
|-- devel
| `-- codeblocks
| |-- Portfile
| `-- files
| |-- codeblocks.plist
| |-- codeblocks.sh.in
| |-- codeblocks-rev3656_pluginslib.patch
| |-- codeblocks-wxauigtk.patch
| `-- dos2unix.sh
`-- graphics
|-- wxGTK
| |-- Portfile
| `-- files
| `-- patch-soundsdl.diff
`-- wxMac
|-- Portfile
`-- files
`-- patch-polling.diff
</pre>

=== Install wxWidgets ===

You will need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After the set up has been done, you can install it with:

<pre>
sudo port install wxMac
</pre>

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

<pre>
sudo port install wxGTK
</pre>

=== Install Code::Blocks ===

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

After the set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T10:37:15Z

Afb: /* Mono Fix */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

Unless you have a "proper" [http://pkgconfig.freedesktop.org/ pkg-config] installation the Code::Blocks configure will fail, so move this symbolic link aside.

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.org/ or http://gnu-darwin.sourceforge.net/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T10:17:04Z

Afb: /* FYI: Darwin vs. Mac OS X */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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://opendarwin.org/ or http://gnu-darwin.sourceforge.net/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T10:14:51Z

Afb: /* Install into Destination */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

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

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T10:13:51Z

Afb: /* (GNU) Make */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T10:11:58Z

Afb: /* Configure and (GNU) Make */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

<pre>
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
</pre>

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

=== (GNU) Make ===

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T10:11:03Z

Afb: /* Apply necessary patches */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

Note: this patch is not needed for wxWidgets 2.6.4 and later

=== Configure and (GNU) Make ===

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

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

=== (GNU) Make ===

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T10:09:51Z

Afb: /* Check Autotools versions */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 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 (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

=== Configure and (GNU) Make ===

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

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

=== (GNU) Make ===

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T10:08:37Z

Afb: /* Libtool example */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 OS X)

Currently Code::Blocks requires versions:
* autoconf 2.50+
* automake 1.7+
* libtool 1.4+ (1.5.8+ highly recommended to get some bug fixes)

=== Automake example (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

=== Configure and (GNU) Make ===

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

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

=== (GNU) Make ===

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T10:01:10Z

Afb: /* Install with DarwinPorts */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 OS X)

Currently Code::Blocks requires versions:
* autoconf 2.50+
* automake 1.7+
* libtool 1.4+ (1.5.8+ highly recommended to get some bug fixes)

=== Automake example (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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-dir/
./configure --prefix=/usr/ --program-prefix=g
make
sudo make install
</pre>

== 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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

=== Configure and (GNU) Make ===

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

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

=== (GNU) Make ===

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets wxWidgets] port is now upgraded to 2.8, and the alternative [http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/wxWidgets26 wxWidgets26] port doesn't yet have all the needed patches)

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T09:51:34Z

Afb: /* FYI: ANSI or UNICODE */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 OS X)

Currently Code::Blocks requires versions:
* autoconf 2.50+
* automake 1.7+
* libtool 1.4+ (1.5.8+ highly recommended to get some bug fixes)

=== Automake example (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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-dir/
./configure --prefix=/usr/ --program-prefix=g
make
sudo make install
</pre>

== 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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

=== Configure and (GNU) Make ===

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

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

=== (GNU) Make ===

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular DarwinPorts version is broken now on Intel though, and it also hardcodes wxMac -see [http://trac.macosforge.org/projects/macports/ticket/10815 Ticket 10815])

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T09:51:09Z

Afb: /* Way Two: Framework (bundle) */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 OS X)

Currently Code::Blocks requires versions:
* autoconf 2.50+
* automake 1.7+
* libtool 1.4+ (1.5.8+ highly recommended to get some bug fixes)

=== Automake example (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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-dir/
./configure --prefix=/usr/ --program-prefix=g
make
sudo make install
</pre>

== 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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6.3/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

=== Configure and (GNU) Make ===

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

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6
/Library/Frameworks/wx.framework/Versions/2.6/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6/libwx_macu-2.6.0.3.1.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.6/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

=== (GNU) Make ===

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular DarwinPorts version is broken now on Intel though, and it also hardcodes wxMac -see [http://trac.macosforge.org/projects/macports/ticket/10815 Ticket 10815])

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T09:49:18Z

Afb: /* Download the source code */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 OS X)

Currently Code::Blocks requires versions:
* autoconf 2.50+
* automake 1.7+
* libtool 1.4+ (1.5.8+ highly recommended to get some bug fixes)

=== Automake example (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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-dir/
./configure --prefix=/usr/ --program-prefix=g
make
sudo make install
</pre>

== 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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6.3/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#previous_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

=== Configure and (GNU) Make ===

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

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6.3
/Library/Frameworks/wx.framework/Versions/2.6.3/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6.3/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6.3/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6.3/libwx_macu-2.6.0.3.1.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.6.3/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

=== (GNU) Make ===

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular DarwinPorts version is broken now on Intel though, and it also hardcodes wxMac -see [http://trac.macosforge.org/projects/macports/ticket/10815 Ticket 10815])

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on Mac OS X

2007-03-22T09:47:51Z

Afb: mono workaround

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
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 and under Mac OS X 10.4
(PowerPC and Intel), and might work on old Mac OS X 10.2 and 10.1 as well.

We will be building everything from scratch using the source code, and
not use any available package managers like
[http://darwinports.opendarwin.org DarwinPorts],
[http://fink.sourceforge.net/ Fink],
[http://gentoo-wiki.com/Gentoo_MacOS Gentoo] or
[http://rpm4darwin.sourceforge.net RPM].
Packaging can be done later, once it has reached a more stable release.

Update: building for DarwinPorts 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/

This will install Apple versions of:

* http://www.gnu.org/software/gcc/ (GNU Compilers)
* http://www.gnu.org/software/gdb/ (GNU Debugger)
* http://www.gnu.org/software/make/ (GNU Make)

Note: 2006/04
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/

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.
For Mac OS X 10.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, the latest Dev Tools.

== Check Autotools versions ==

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

* http://www.gnu.org/software/autoconf/ (GNU Autoconf)
* http://www.gnu.org/software/automake/ (GNU Automake)
* 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 OS X)

Currently Code::Blocks requires versions:
* autoconf 2.50+
* automake 1.7+
* libtool 1.4+ (1.5.8+ highly recommended to get some bug fixes)

=== Automake example (Panther) ===

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

You can download "[ftp://ftp.gnu.org/gnu/automake/automake-1.7.9.tar.gz automake-1.7.9.tar.gz]" and configure and install it with something like:

<pre>
./configure --prefix=/usr/local --program-suffix=-1.7
make
sudo make install
sudo cp -pi /usr/share/aclocal/libtool.m4 /usr/local/share/aclocal-1.7/
</pre>

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

On Mac OS X 10.4.8, i downloaded and installed version 1.9. I configured without any options and followed the same steps as above. I just replaced 'automake-1.7' and 'aclocal-1.7' in the bootstrap section by 'automake-1.9' and 'aclocal-1.9' and everything worked.

=== Libtool example ===
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-dir/
./configure --prefix=/usr/ --program-prefix=g
make
sudo make install
</pre>

== 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:
<pre>
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"

CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
</pre>
(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 "[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:
* 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 [http://developer.apple.com/technotes/tn2005/tn2137.html Technical Note TN2137]: Building Universal
Binaries from "configure"-based Open Source Projects

== 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/2.6.3/wx_unicode.html#unicodeandansi

== Build wxWidgets 2.6 ==

=== Download the source code ===

Download the tarball for the wxMac release:

http://wxwidgets.org/downloads/#latest_stable

=== Apply necessary patches ===

Don't forget to apply any released patches!

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

For Intel Macintosh, you will need this additional patch:

* http://www.algonet.se/~afb/wx/wxWidgets-killpoll.patch

<pre>
patch -p1 -i wxWidgets-killpoll.patch
</pre>

=== Configure and (GNU) Make ===

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

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

=== Install into Destination ===

<pre>
sudo make install
</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.6/wx/wx.h
/usr/local/lib/libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib
/usr/local/lib/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/usr/local/lib/libwx_macu-2.6.0.3.1.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.6.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.6.3
/Library/Frameworks/wx.framework/Versions/2.6.3/Headers/wx.h
/Library/Frameworks/wx.framework/Versions/2.6.3/wx -> libwx_macu-2.6.0.dylib
/Library/Frameworks/wx.framework/Versions/2.6.3/libwx_macu-2.6.0.dylib -> libwx_macu-2.6.0.3.1.dylib
/Library/Frameworks/wx.framework/Versions/2.6.3/libwx_macu-2.6.0.3.1.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.6.3/libwx_macu-2.6.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 ==

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

<pre>
svn checkout svn://svn.berlios.de/codeblocks/trunk
cd trunk
</pre>

=== Apply necessary patches ===

For a list of necessary patches, see below under "DarwinPorts", or:

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

<pre>
patch -p0 -i codeblocks-rev3656_pluginslib.patch
</pre>

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

Hopefully most of these should be merged upstream, before release:

* http://developer.berlios.de/patch/?func=detailpatch&patch_id=1395&group_id=5358

(when they are, the above stand-alone patches might fail to apply)

=== Bootstrap with Autotools ===

You need to use the newer version of automake, for the "bootstrap":

<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

See above for how to compile and install automake-1.7 on Mac OS X.

=== Mono Fix ===

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

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

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

=== Configure ===

<pre>
./configure --enable-contrib
</pre>

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.

<pre>
mkdir ppc-build
cd ppc-build
../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib
cd ..

mkdir x86-build
cd x86-build
../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib
cd ..
</pre>

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:

<pre>
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
</pre>

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

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

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

=== (GNU) Make ===

<pre>
nice make
</pre>

For the Universal Binary build:

<pre>
cd ppc-build
nice make
cd ..

cd x86-build
nice make
cd ..
</pre>

=== Install into Destination ===

<pre>
sudo make install
</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 ==

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 only need to add an icon.

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:

<pre>
$PREFIX/bin
$PREFIX/lib
$PREFIX/share/codeblocks
</pre>

Add a custom icon to the application, and make it receive events:

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

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

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:

<pre>
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib
export DYLD_LIBRARY_PATH

$PREFIX/bin/codeblocks --prefix=$PREFIX
</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>

DarwinPorts: <tt>PREFIX=/opt/local</tt>

Fink: <tt>PREFIX=/sw</tt>

=== Way Two: NeXT (bundle) ===

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

This does not involve resources, and is more relocatable.

Files needed:
* http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist (rename to "Info.plist")
* http://www.algonet.se/~afb/wx/CodeBlocks.sh (shell wrapper, rename to "CodeBlocks")
* http://www.algonet.se/~afb/wx/CodeBlocks.icns (Mac OS X icon, rename to "app.icns")

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

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

== 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/

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

== Install with DarwinPorts ==

To build and install Code::Blocks, you will need:

* http://www.algonet.se/~afb/wx/codeblocks.Portfile

The following need to go in the "files" directory:

* http://www.algonet.se/~afb/wx/codeblocks.plist
* http://www.algonet.se/~afb/wx/codeblocks.sh.in
* http://www.algonet.se/~afb/wx/dos2unix.sh
* http://www.algonet.se/~afb/wx/codeblocks-rev3656_pluginslib.patch
* http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch

Put the Portfile in your local DarwinPorts tree (usually in <tt>~/dports</tt> - set up in <tt>/opt/local/etc/ports/sources.conf</tt>, create the directory if needed), as <tt>dports/devel/codeblocks/Portfile</tt> and download the helper files to <tt>dports/devel/codeblocks/files</tt>. (then do a chdir to <tt>dports</tt>, and run the <tt>/opt/local/bin/portindex</tt> command)

You will also need these custom wxWidgets ports:

* http://www.algonet.se/~afb/wx/wxMac.Portfile
* http://www.algonet.se/~afb/wx/patch-polling.diff
* http://www.algonet.se/~afb/wx/wxGTK.Portfile
* http://www.algonet.se/~afb/wx/patch-soundsdl.diff

The optional wxWidgets file go in <tt>graphics/wx{Mac,GTK}/Portfile</tt>. Normally one use the regular wxWidgets port from the DarwinPorts main, but that should in turn use wxMac on Mac OS X and wxGTK on Pure Darwin so it is all the same software. (the regular DarwinPorts version is broken now on Intel though, and it also hardcodes wxMac -see [http://trac.macosforge.org/projects/macports/ticket/10815 Ticket 10815])

After that set up has been done, you can install it with:

<pre>
sudo port install codeblocks
</pre>

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

<pre>
sudo port install codeblocks -macosx+puredarwin
</pre>

This will download the SVN trunk, and any dependencies:

<pre>
---> Fetching codeblocks
---> Verifying checksum(s) for codeblocks
---> Extracting codeblocks
---> Applying patches to codeblocks
---> Configuring codeblocks
---> Building codeblocks with target all
---> Staging codeblocks into destroot
---> Packaging tgz archive for codeblocks 1.0_0+macosx
---> Installing codeblocks 1.0_0+macosx
---> Activating codeblocks 1.0_0+macosx
---> Cleaning codeblocks
</pre>

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

<pre>
sudo port uninstall codeblocks
sudo port clean codeblocks
sudo port install codeblocks
</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>+macosx</tt> (wxMac) version ===

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

<pre>
open /Applications/DarwinPorts/CodeBlocks.app
</pre>

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

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

=== Running <tt>+puredarwin</tt> (wxGTK) version ===

The non-bundled wxGTK version is instead started with:

<pre>
/opt/local/bin/codeblocks --prefix=/opt/local
</pre>

There is also a wxGTK startup command in "DarwinPorts",
that will first start up X11.app and then launch C::B:

<pre>
open /Applications/DarwinPorts/CodeBlocks.command
</pre>

Installing Code::Blocks from source on RPM based distributions

2007-03-05T11:02:56Z

Afb: /* Non-root rpmbuild environment (recommended) */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]

== Install Requirements ==

Note: Code::Blocks requires GTK+ 2.x. Older distributions might only support GTK+ 1.x.

=== Install Development Tools ===

This has to be installed before starting:
* zip
* update-desktop-files (only on SUSE)
* make
* gettext
* autoconf >= 2.5
* automake >= 1.7
* libtool >= 1.4
* m4
* intltool
* gcc-c++
* libstdc++-devel

In Fedora/CentOS, this can be done with:
<pre>
su -c 'yum groupinstall "Development Tools"'
su -c 'yum install intltool'
</pre>

==== Install newer autotools versions (if needed) ====

If you have CentOS 3 or RHEL 3, you will need to rebuild "automake17" to use instead of automake-1.6:
* ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/automake17-1.7.9-5.src.rpm
<pre>
rpmbuild --rebuild automake17-1.7.9-5.src.rpm
</pre>

Then you need to invoke bootstrap like this, both on the commandline and in codeblocks.spec:
<pre>
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
</pre>

=== Setup RPM environment ===

This has to be installed before starting:
* rpm-build

The top work directory for RPM varies between distributions and setups, but you can find your RPM top dir by setting a variable like:

<pre>
RPM_TOPDIR=`rpm --eval %{_topdir}`
echo $RPM_TOPDIR
</pre>

==== Non-root rpmbuild environment (recommended) ====

It is recommended that you don't use the root account to build packages, here is how you set up a minimal user build environment:

<pre>
cd
mkdir rpm
echo "%_topdir $HOME/rpm" >> .rpmmacros
mkdir /tmp/$USER/rpm
echo "%_tmppath /tmp/$USER/rpm" >> .rpmmacros
cd rpm
mkdir SPECS SOURCES BUILD RPMS SRPMS
RPM_TOPDIR=`rpm --eval %{_topdir}`
</pre>

You can now build packages without being root (assuming that the spec files are correct). You will still need root access to install.

=== Install wxWidgets 2.6.x ===

The build requirements in the source RPM are set to a minimum. So it isn't checked whether wxGTK is installed or not. So you have to take a look at it yourself.

This has to be installed:
# wxGTK >= 2.6.0 and its devel package (see [http://wxwidgets.org wxwidgets.org])
# wxGTK-xrc and its devel package (in some distributions included in the packages of point 1)

In later Fedora, this can be done with:
<pre>
su -c 'yum install wxGTK-devel'
</pre>

==== Build the wxGTK RPM from source (if needed) ====

TODO

* http://prdownloads.sourceforge.net/wxwindows/wxGTK-2.6.3.tar.gz
* ftp://biolpc22.york.ac.uk/pub/2.6.3/wxWidgets-2.6.3-Patch-2.tar.gz
* http://www.algonet.se/~afb/wx/wxGTK.spec

RPMS

* wx-base-unicode-2.6.3.0.2-1.i386.rpm
* wx-base-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-gl-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-contrib-devel-2.6.3.0.2-1.i386.rpm
* wx-gtk2-unicode-debuginfo-2.6.3.0.2-1.i386.rpm
* wx-i18n-2.6.3.0.2-1.i386.rpm

=== Install Subversion client ===

This has to be installed before starting:
* subversion >= 1.4.0, (see [http://subversion.tigris.org subversion.tigris.org])

Binary packages for Red Hat Linux 9, Fedora Core 1, CentOS 3, CentOS 4 at:

http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/

In later Fedora, this can be done with:
<pre>
su -c 'yum install subversion'
</pre>

==== Build Subversion RPM from source (if needed) ====

TODO

* http://subversion.tigris.org/downloads/subversion-1.4.2.tar.gz
* packages/rpm/rhel-3/subversion.spec (CentOS 3)
* packages/rpm/rhel-4/subversion.spec (CentOS 4)

RPMS

* subversion-1.4.2-1.i386.rpm
* subversion-devel-1.4.2-1.i386.rpm
* subversion-perl-1.4.2-1.i386.rpm
* subversion-python-1.4.2-1.i386.rpm
* subversion-tools-1.4.2-1.i386.rpm
* subversion-debuginfo-1.4.2-1.i386.rpm

== Install Code::Blocks ==

=== Download the Source RPM ===

1. Download the Source RPM from [https://www.codeblocks.org/downloads.shtml www.codeblocks.org/downloads.shtml]

==== Prepare SRPM package from SVN (if needed) ====

1. You need to get the latest sources from SVN [https://www.codeblocks.org/source_code.shtml www.codeblocks.org/source_code.shtml]

2. go into ''trunk'', if you haven't already done it.

3. run these three commands in this order
./bootstrap
./configure --enable-contrib
make dist
the last one will create a .tar.gz archive that contains the sources.

4. copy the archive to the directory $RPM_TOPDIR/SOURCES
sudo mv codeblocks-trunk-r$REVISION.tar.gz $RPM_TOPDIR/SOURCES

5. build the source RPM, or copy spec to $RPM_TOPDIR/SPECS
rpmbuild -bs codeblocks.spec

This will create a source package in the directory $RPM_TOPDIR/SRPMS/.

=== Build the RPM package ===

1. Build the binary package
rpmbuild --rebuild codeblocks-1.0*.src.rpm

This will create several packages in one of the architecture specific subdirectories (i386, x86_64, ppc, ...) of $RPM_TOPDIR/RPMS/.

These are:
* codeblocks: main package
* codeblocks-contrib: contrib plugins
* codeblocks-devel: SDK headers
* codeblocks-debuginfo: stripped debug information

=== Install the RPM package ===

Install as root the packages you want (usually codeblocks and codeblocks-contrib) and enjoy Code::Blocks!