Getting started on OS X
From WxWiki
|
| | This section contains information which may be of questionable relevance to the article's subject matter. Please help improve this article by clarifying or removing superfluous information. | |
These instructions describe how to use wxWidgets 2.8.4 with Xcode for Mac OS X.
Other articles are available for older versions. You can also view older revisions of this article by clicking 'history' at the top.
- Written by Tim Griesser, February 28, 2004 for wxWidgets 2.4.2
- Updated by Tim Griesser, June 18, 2004 for wxWidgets 2.5.2 and CVS HEAD
- Updated by Tim Griesser, December 8, 2004 for wxWidgets 2.5.3 and Xcode 1.5
- Updated by Tim Griesser, June 16, 2005 for wxWidgets 2.6.1 and Xcode 2.0
- Thanks also to John Mehringer, Paul Heller, Fredrik Roubert,and Kemp Cease
- Updated September 28, 2006 for wxWidgets 2.6.3 and Xcode 2.3
- Minor Update by Geoff Ericksson, December 7, 2006 for MacPorts and Xcode Project Templates
- Updated by Marianne Gagnon, June 24 2007, to clean up the mess and update to 2.8.4 (removed the quick and dirty duplicate instructions at top and merged them with the body of the article) Updated to SVN
- Minor updates by Matt Browne, January 2, 2008 to note additional Xcode configuration options that may be needed in order to get the sample running.
- Updated by Kip Warner, February 20, 2008 to note linker problems under Leopard.
[edit] Installing wxWidgets from Source
[edit] Getting the Source
See Downloading and installing wxWidgets.
[edit] Compiling wxWidgets from Xcode
Note: Compiling from the terminal (explained below) is better supported, and more reliable.
Information updated and moved to Compiling wxWidgets with Xcode
[edit] Samples and Xcode
Now, time to try samples. Note that not all samples have Xcode projects.
- Navigate to the ~/wxMac-2.8.4/samples/minimal folder. In there you will find a file called "minimal.xcodeproj" (NOT just minimal.xcode) double click on it to launch it.
- From the Xcode minimal window click on the Active Target dropdown menu and select "All Targets". Click on the build icon.
- Navigate to ~/wxMac-2.8.4/samples/minimal/build/Development. There you will find the two applications all your work has just produced: "minimal" and "minimalDynamic".
[edit] Dynamic Library Install Directory
In Mac OS X, the run time dynamic library loader wants to know exactly where all of the dylibs are. Most frameworks are installed in the system files, and to be safe Xcode normally builds against an OS SDK (eg 10.4u SDK) which is a known configuration of 10.4 systems that you're application can link to. (So you don't need to copy the libraries).
Mac OS X 10.4 ships with wxWidgets 2.5 pre-installed, for interest's sake.
Mac OS Applications are packages, which also makes it easy for you to copy the dylib into your app's package folder, and the linker will find it. With the Xcode project above (2.8.4), this layout will work:
myProgram.app/ myProgram.app/Contents myProgram.app/Contents/MacOS myProgram.app/Contents/MacOS/myProgram <-- this is your executable myProgram.app/Contents/Frameworks/wxmac.dylib <-- this is the dynamic library output of the wxWindows Xcode project. (other files suchs as Info.plist have been omitted from this list)
To achieve this in your program's Xcode project, add a build phase to "Copy Files" and copy to the Executable path, with a subpath of "../Frameworks". Then when you build your app, Xcode will copy the dylib into the app's package where the linker can find it. And your app is linking to a relative path, which is easily transportable!
Note that this will work automatically only if you built wxWidgets using the Xcode project. If you built using gnu autotools, and wish to bundle wxWidgets inside the app bundle :
- Use static binaries if you can, they save you all that trouble.
- Otherwise, if you really need dynamic librairies, check otool (especially otool -L) and install_name_tool on the terminal
- http://macdylibbundler.sf.net does the same but more automatised
[edit] Compiling wxWidgets from the Terminal
Information moved to Compiling wxWidgets using the command-line (Terminal)
[edit] Mac OS X Leopard (10.5) Notes
On this system you might run into some nifty problems if you use the latest SDK, build from the command line, and want to run the resulting binary under 10.4 as well. So for the moment, please use --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk and specifiy a 10.3 (http://wiki.wxwidgets.org/Main_Page2.8 branch) or 10.4 (trunk) minimal system --with-macosx-version-min=10.4. When you build the Xcode project, make sure to follow the instructions described in the Creating Xcode projects for wxWidgets applications article (you will need to change a few settings about symbol visibility). You will get get visibilty errors if you don't do so.
Alternatively, if you don't want to change visiblity settings in Xcode (should be a very special case, for almost all common uses the first method described above should work fine), you can instead change visiblity settings in wxWidgets itself by setting this before building :
export LDFLAGS='-flat_namespace'
Some HIShape calls have been moved from one framework to another, therefore the usual two-level namespace handling of the linker stores a 10.5 location and cannot find the corresponding call when running under 10.4, flattening the namespace is the current workaround.
[edit] Install wxWidgets with MacPorts
If you have MacPorts (formerly known as DarwinPorts) already installed on your machine then wxWidgets can be installed simply running the command
sudo port install wxWidgets
[edit] Troubleshooting Compile-Time Errors
- If Xcode can't find a header *.h file, go back and check your build settings. There's probably some flags from wx-config missing or misplaced.
- You can also check the full build log from Xcode, and compare it with those that Sample Makefiles output.
- If you ever changed the parameters to ./configure, you must always remove the prior build directory first and start from scratch in a new directory. Otherwise you can get a mixture of old and new files in the directory which will confuse the compiler, confuse you, and lead to strange errors and warnings.
- Make sure you don't enable monolithic build (--enable-monolithic) if you are generating a static library (--disable-shared). wxWidgets will probably build and install fine, until you try to link against the libraries with your code or one of the samples. You probably have monolithic and static enabled together (while they are mutually exclusive for some reason) if you see something like this:
Undefined symbols for architecture i386:
"wxTopLevelWindowMac::DoCentre(int)", referenced from:
vtable for MyFramein minimal_minimal.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
[edit] Troubleshooting Run-Time Errors
If you program compiles in debug mode but will not run, check for a Zero Link unknown object error. wxWidgets will not work if ZeroLink is enabled. You can switch it off in Project Info->Build->Linking
If your program crashes when compiled from Xcode, but does not crash when compiled from the "samples" makefile, then it means that your compiler settings in Xcode do not match the compiler settings you used when you compiled the wxWidgets library (like defining __WXDEBUG__ and linking against release librairies, or vice-versa)
If you want to debug beyond your code and into the wxWidgets code, you need to do three things:
- Build a debug version of the wxWidgets library (see articles about building wxWidgets)
- Add this debug library to your Xcode project, clean and rebuild.
- Add the __WXDEBUG__ compile flag to your project.
[edit] See Also
- WxMac Issues
- Xcode 3.1 Project Setup Guide
- Making your app look good for OS X
- Useful Xcode Data Formatters (Data formatters allow you to cutomize how variables are displayed in Xcode).
- Setting Environment Variable For XCode
- Building WxWidgets With MacOS X
