Difference between revisions of "Installing Code::Blocks from source on Mac OS X"
m (example configure lines) |
|||
Line 214: | Line 214: | ||
There are two ways of accomplishing this, old Mac OS-style resource or NeXT-style bundle. | 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. | 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 1. Mac OS (resource) === | === Way 1. Mac OS (resource) === |
Revision as of 14:58, 23 August 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, but 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.
Install Xcode Tools
If they didn't come bundled with Mac OS X, get the Xcode Tools (or Developer Tools for older Mac OS X) from:
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.3, you want Xcode 1.5. For Mac OS X 10.1-10.2, 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/
- http://www.gnu.org/software/automake/
- http://www.gnu.org/software/libtool/
Check what you have, with --version (note that GNU libtool is called "glibtool" on Mac)
Currently Code::Blocks requires versions:
- autoconf 2.50+
- automake 1.7+
- libtool 1.4+
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 --program-suffix=-1.7 make sudo make install
Since it's now known as "automake-1.7", it won't interfere with the regular "automake"
Universal Binaries
If you are building for Mac OS X 10.4, you might want to build "Universal Binaries " These are binaries that contain code for both PowerPC ("powerpc") and Intel ("i686")
The basic flags that needs to be added are:
CFLAGS += "-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 Mac release
http://wxwidgets.org/downloads/#latest_stable
Configure and (GNU) Make
./configure --enable-shared --enable-monolithic --with-opengl --with-mac \ --with-png=builtin --with-tiff=builtin --with-jpeg=builtin && 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
Install Subversion client
Build CodeBlocks from SVN
Download the source code
https://www.codeblocks.org/source_code.shtml
Bootstrap with Autotools
The "bootstrap" script doesn't work on Mac OS X, so do it manually:
./update_revision.sh glibtoolize --force --copy && \ aclocal-1.7 && \ cat /usr/share/aclocal/libtool.m4 >> aclocal.m4 && \ autoheader && \ automake-1.7 --include-deps --add-missing --foreign --copy && \ autoconf
Configure
LDFLAGS="`wx-config --libs`" ./configure --disable-code-completion
Note: all the plugins fail to link on Mac OS X, since codeblocks refers to wxWidgets libs (this is why there is an extra LDFLAGS invocation in the above, until it has been fixed)
ld: object_file illegal reference to symbol: *** defined in indirectly referenced dynamic library: ***
Note: couldn't get the code completion code to work, so disabling it (for now, rev 2886) It seems that this only happens with old GCC 3.3, since it did build OK with GCC 4.0...
nativeparser.cpp: In member function `size_t NativeParser::FindAIMatches(Parser*, std::queue<ParserComponent, std::deque<ParserComponent, std::allocator<ParserComponent> > >, TokenIdxSet&, int, bool, bool, bool, short int, TokenIdxSet*)': nativeparser.cpp:1379: error: no match for `std::_Rb_tree_iterator<int, const int&, const int*>& == int' operator nativeparser.cpp:1381: error: no match for `std::_Rb_tree_iterator<int, const int&, const int*>& != int' operator nativeparser.cpp:1394: error: no match for `std::_Rb_tree_iterator<int, const int&, const int*>& == int' operator
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 afterwards.
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
Install into Destination
sudo make install
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 1. 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
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
Way 2. 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)
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).
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/CodeBlocks.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.