Author Topic: Code::Blocks, wxWidgets and Mac OS X  (Read 21403 times)

Offline BastiaanOlij

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Code::Blocks, wxWidgets and Mac OS X
« Reply #15 on: June 18, 2014, 02:10:08 am »
Just searched for the error, but removed the unique parts of it...
Like this:
Code
ld: internal error: atom not found in symbolIndex() for architecture x86_64


Weird, I'm pretty sure I tried something similar. Alas, the mysteries of googles search optimisation I guess, I must have included that one thing extra that made it put a useful post all the way down a few pages...

Anyway, this problem solved, on to the next one :)

Thanks loads man! much appreciated!

Offline BastiaanOlij

  • Multiple posting newcomer
  • *
  • Posts: 10
[SOLVED] Code::Blocks, wxWidgets and Mac OS X
« Reply #16 on: June 18, 2014, 02:19:58 pm »
Hi Everyone,

Just to complete this post so anyone who wants to start with Code::Blocks and wxWidgets on Mac OS X has a helping hand as I'm pretty sure I'm not the only one who will have these issues.

1) make sure you have XCODE installed and install the command line tools (you'll find the option in preferences somewhere)

2) Compiling wxWidgets, as at the beginning of my post, I personally like compiling it as a static library, larger executable file but I'm fine with that.
Just to keep things clear I'm going to use ~/devel as the root of everything (~ is your home folder)
Download wxWidgets source code, unzip the file in this folder. The folder by default has the version of wxWidgets embedded. I'm going to assume you rename the folder to wxWidgets or add a symlink with that name. Makes life easier.

First order of business, configure wxWidgets:
Code
cd ~/devel/wxWidgets
mkdir build-cocoa
cd build-cocoa
../configure --enable-monolithic --disable-shared
make
sudo make install

Note that this will compile wxWidgets for your hardware, so i386 on an intel Mac, x86_64 on a 64bit mac, forget about PPC.
There should be a flag to create a universal binary so it supports both i386 and x86_64, I'll update this post once I know it

3) create your C::B project using the wxWidgets project template.
First off, if you want things to work straight forward you'll need to start C::B from your terminal session.Once I know what ingredients are missing that would allow you to start C::B directly from finder I'll add that in here. The other option is to run wx-config --cflags and wx-config --libs and copying the values returned into your compiler and linker settings

Then untick the -s compiler flag in Projects->build options as it will cause the linker to fail.

4) If you compile the source code now it will compile but when you run your app you'll get a:
Code
classic environment is no longer supported 

This is because the standard project runs a command at the end that adds carbon resources to the file. From what i can find this is a workaround to get programs to run without first turning them into a bundle. As far as I can tell this doesn't work anymore, atleast not on 10.8.5

Clear out the post build steps to prevent C::B from running this step.

I'm going to investigate how to build the app as a proper bundle but here is my poor mans version:
Code
mkdir ~/devel/test/bin/release/test.app
mkdir ~/devel/test/bin/release/test.app/Contents
mkdir ~/devel/test/bin/release/test.app/Contents/MacOS
mkdir ~/devel/test/bin/release/test.app/Contents/Resources

At this point you can rightclick on test.app in the finder and open contents to do the following actions

Copy your executable file (probably called test) into ~/devel/test/bin/release/test/Contents/MacOS/
Then you need to create a file called ~/devel/test/bin/release/test.app/Contents/Info.plist
Here is a sample of what could be in this file:
Code
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>test</string>
<key>CFBundleGetInfoString</key>
<string>Test Widgets</string>
<key>CFBundleIdentifier</key>
<string>com.yourcompany.test</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>Test Widgets</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>usingBundleAsContainer</key>
<true/>
<key>CFBundleIconFile</key>
<string>test.icns</string>
</dict>
</plist>

The key CFBundleExecutable is very important, this should match the name of the executable you build.

Finally you need to get an icon file from somewhere or make one. Name it icon.icns and place it into ~/devel/test/bin/release/test.app/Contents/Resources

Now your app works and every time you build just copy the executable in place.

Obviously the next step is to make this part of the build process itself and have both the plist and icons file be part of the source. I'm not sure if this is the correct way to create the application bundle or if there are tools as part of the xcode toolset to automate this.

I hope to have more time on my hands in the coming week and if i figure this out I'll be sure to post better instructions :)
« Last Edit: June 18, 2014, 11:43:43 pm by BastiaanOlij »