Difference between revisions of "Installing Code::Blocks from source on Mac OS X"
Line 138: | Line 138: | ||
=== Way One: Library (dynamic) === | === Way One: Library (dynamic) === | ||
+ | |||
+ | <pre> | ||
+ | install_name_tool -id @executable_path/libwx_mac-2.6.0.dylib libwx_mac-2.6.0.dylib | ||
+ | </pre> | ||
=== Way Two: Framework (bundle) === | === Way Two: Framework (bundle) === |
Revision as of 14:00, 4 November 2006
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 should work under Mac OS X 10.4 (PowerPC and Intel) and 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 DarwinPorts, Fink, Gentoo or 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 --version (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+
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 "automake-1.7.9.tar.gz" and configure and install it with something like:
./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/
Since it's now known as "automake-1.7", it won't interfere with the regular "automake"
FYI: Universal Binaries
If you are building for Mac OS X 10.4 or later, you might want to build "Universal Binaries " These are binaries that contain code for both PowerPC ("ppc" arch) and Intel ("i386" arch)
The basic flags that needs to be added are:
CFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" CXXFLAGS += "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
(You only need the sysroot parameter on PowerPC Macintosh, not on a Intel Macintosh) The "-arch i386 -arch ppc" is what tells the compiler to build a "universal" (or "fat") binary.
Usually it's easiest to build one version for "powerpc-apple-darwin8", and one version for "i686-apple-darwin8", and then merge them with "lipo"
./configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 ./configure --host=i686-apple-darwin8 --target=i686-apple-darwin8
Some caveats:
- pre-compiled headers might fail with a "no main" error. If they do, add a -c to only compile them
- when cross-compiling, tools like auto_revision might fail to build. copy these from a native build
- the Tiger compilers might crash from time to time, but that is only to be expected (it seems)...
See Technical Note TN2137: Building Universal Binaries from "configure"-based Open Source Projects
Build wxWidgets 2.6
Download the wxMac release
http://wxwidgets.org/downloads/#latest_stable
Don't forget to apply any released patches!
http://wxwidgets.org/downloads/patch.htm
For Intel Macintosh, you will need this patch:
patch -p1 -i wxWidgets-killpoll.patch
Configure and (GNU) Make
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
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
sudo make install
Bundle library for Mac
TODO
Way One: Library (dynamic)
install_name_tool -id @executable_path/libwx_mac-2.6.0.dylib libwx_mac-2.6.0.dylib
Way Two: Framework (bundle)
Install Subversion client
Note: you need SVN for the Code::Blocks revision scripts to work!
Build CodeBlocks from SVN
Download the source code
https://www.codeblocks.org/source_code.shtml
svn checkout svn://svn.berlios.de/codeblocks/trunk cd trunk
Apply necessary patches
For a list of necessary patches, see below under "DarwinPorts", or:
http://developer.berlios.de/patch/?group_id=5358
patch -p0 -i codeblocks-rev2970_pkgconfig.patch patch -p0 -i codeblocks-rev3146_pluginslib.patch
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=1474&group_id=5358
- 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":
AUTOMAKE=automake-1.7 ACLOCAL=aclocal-1.7 ACLOCAL_FLAGS="-I /usr/share/aclocal" ./bootstrap
See above for how to compile and install automake-1.7 on Mac OS X.
Configure
./configure --enable-contrib
Note: the easiest way to build a Universal Binary for Code::Blocks is to build once for PowerPC (-arch ppc) and once for Intel (-arch i386), and then merge them (with lipo) afterwards.
mkdir ppc-build cd ppc-build ../configure --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 --enable-contrib cd .. mkdir x86-build cd x86-build ../configure --host=i686-apple-darwin8 --target=i686-apple-darwin8 --enable-contrib cd ..
Note: You need to patch the location of the pre-compiled headers, or it will generate them in the same place for both arch.
Tiger Fix
There is a bug in the glibtool of Mac OS X 10.4, that fails to link C++ libs:
ld: multiple definitions of symbol ___umoddi3 /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_umoddi3.o) private external definition of ___umoddi3 in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_umoddi3_s.o) definition of ___umoddi3 ld: multiple definitions of symbol ___umoddi3 /usr/lib/gcc/i686-apple-darwin8/4.0.1/libgcc.a(_umoddi3.o) private external definition of ___umoddi3 in section (__TEXT,__text) /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(_umoddi3_s.o) definition of ___umoddi3
To work around this, you need to edit the generated "libtool" script manually:
177c177 < whole_archive_flag_spec="-all_load \$convenience" --- > whole_archive_flag_spec="" 6921c6921 < whole_archive_flag_spec="-all_load \$convenience" --- > whole_archive_flag_spec=""
This bug has been fixed in GNU libtool 1.5.8 and later.
(GNU) Make
nice make
For the Universal Binary build:
cd ppc-build nice make cd .. cd x86-build nice make cd ..
Install into Destination
sudo make install
For the Universal Binary build:
cd ppc-build make install DESTDIR=/tmp/ppc cd .. cd x86-build make install DESTDIR=/tmp/x86 cd .. lipomerge /tmp/ppc /tmp/x86 /tmp/fat
Where "lipomerge" is a custom shell script:
Bundle application for Mac
After building codeblocks in the regular Unix way, you need to bundle it with the icons and various other info that it needs to make a regular stand-alone Macintosh application.
There are two ways of accomplishing this, old Mac OS-style resource or NeXT-style bundle. The old resources are handy while developing, while bundles are more suitable for release.
Note: You need to use either of these methods, or your application will launch in the background behind all other windows and will be unable to receive any events!
Way One: Mac OS (resource)
http://developer.apple.com/documentation/Carbon/Reference/Resource_Manager/
Handy while developing, as you 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:
$PREFIX/bin $PREFIX/lib $PREFIX/share/codeblocks
Add a custom icon to the application, and make it receive events:
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
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:
sudo `wx-config --rezflags` $PREFIX/bin/codeblocks
Start the application with a small prefix shell wrapper like this:
DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$PREFIX/lib export DYLD_LIBRARY_PATH $PREFIX/bin/codeblocks --prefix=$PREFIX
You don't need the "DYLD_LIBRARY_PATH" stuff, if you are installing to a system directory.
Common PREFIX Settings
Local: PREFIX=/usr/local
System: PREFIX=/usr
DarwinPorts: PREFIX=/opt/local
Fink: PREFIX=/sw
Way Two: NeXT (bundle)
http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/
This does not involve resources, and is more relocatable.
Files needed:
- 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":
mv bin/codeblocks MacOS/CodeBlocks rmdir bin mv lib/* MacOS/ rmdir lib mv share/codeblocks/* Resources/ rmdir share/codeblocks rmdir share
To avoid having to use a DYLD_LIBRARY_PATH, we rename the shared libraries (with the install_name_tool program) from e.g. /usr/local/lib/ to @executable_path/:
install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib \ @executable_path/libcodeblocks.0.dylib MacOS/CodeBlocks
The libraries can have their names changed using the -id parameter:
install_name_tool -id @executable_path/libcodeblocks.0.dylib MacOS/libcodeblocks.0.dylib
You also need to change all of the loadable bundles for the plugins:
for so in Resources/plugins/*.so do install_name_tool -change /usr/local/lib/libcodeblocks.0.dylib \ @executable_path/libcodeblocks.0.dylib $so done
You can check the result, what libraries/frameworks it links to, with:
otool -L CodeBlocks
Optionally you can then repeat the process, for the wx library too...
FYI: Darwin vs. Mac OS X
"Darwin is the UNIX technology-based foundation of Mac OS X."
"Pure Darwin" here refers to the Open Source version of the OS:
(that is: Darwin using X11 instead of Aqua for the user interface)
Install with DarwinPorts
To build and install Code::Blocks, you will need:
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-rev2970_pkgconfig.patch
- http://www.algonet.se/~afb/wx/codeblocks-rev3146_pluginslib.patch
- http://www.algonet.se/~afb/wx/codeblocks-appselfpath.patch
- http://www.algonet.se/~afb/wx/codeblocks-wxauigtk.patch
Put the Portfile in your local DarwinPorts tree (usually in ~/dports - set up in /opt/local/etc/ports/sources.conf, create the directory if needed), as dports/devel/codeblocks/Portfile and download the helper files to dports/devel/codeblocks/files. (then do a chdir to dports, and run the /opt/local/bin/portindex command)
Optionally and for reference, you might want these:
- 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 graphics/wx{Mac,GTK}/Portfile. Normally the port uses 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 though, and hardcodes wxMac, see Ticket 10815)
After that set up has been done, you can install it with:
sudo port install codeblocks
If you want the X11/GTK version on Mac OS X, instead use:
sudo port install codeblocks -macosx+puredarwin
This will download the SVN trunk, and any dependencies:
---> 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
Note: to upgrade from SVN, you need to uninstall first:
sudo port uninstall codeblocks sudo port clean codeblocks sudo port install codeblocks
This is both because all SVN versions are numbered "0", but also due to a bug in the Code::Blocks build scripts.
Running +macosx (wxMac) version
After the build completes, you can start the program by:
open /Applications/DarwinPorts/CodeBlocks.app
Note that the wxMac application bundle in "DarwinPorts" is just a wrapper, with symbolic links to /opt/local...
/opt/local/bin/codeblocks --prefix=/opt/local
Running +puredarwin (wxGTK) version
The non-bundled wxGTK version is instead started with:
/opt/local/bin/codeblocks --prefix=/opt/local
There is also a wxGTK startup command in "DarwinPorts", that will first start up X11.app and then launch C::B:
open /Applications/DarwinPorts/CodeBlocks.command