Developers

Linking C++ code in with Objective C code

You would think this should be no problem, but you would be wrong. For an Objective C file to have it’s code access logic that uses C++ code, such as the STL, it needs to be compiled by the C++ compiler, not the C compiler. This does not happen automatically. To make it work, add ‘-lstdc++’ to the ‘Other Linker Flags’. If you don’t you will get some of the dreaded and completely unobvious following errors:

Undefined symbols for architecture x86_64:

“___cxa_begin_catch”, referenced from: …

“___cxa_end_catch”, referenced from: …

“___cxa_rethrow”, referenced from: …

“___gxx_personality_v0”, referenced from: …

Upgrade Subversion in Xcode Without Upgrading Xcode.

So, in the later versions of Xcode, namely 4.3 and up, the subversion client that it uses is built in to the Xcode package, so if you upgrade your command-line client, Xcode will not be using it.

To fix this Apple would have you upgrade Xcode. This is not always possible though for various reasons. (In my case, the newest version of Xcode only runs on OSX 10.8 and up, and My computer is just a tiny bit too old to be supported by that OS.)

The alternative is to change the Xcode package (this is easier than it seems). The way I did it was to make sure my command-line svn client was at the version I want, and then replace the client built in to the Xcode package with soft links to the command-line version (in my case it is at /opt/subversion/bin). Here is the procedure from Terminal:

> sudo -s

{hvanbrug -> root} Password:> cd /Applications/Xcode.app/Contents/Developer/usr/bin

> mkdir subversion_bkup

> mv svn* subversion_bkup

> ln -s /opt/subversion/bin/svn* ./

and that’s all there is to it. Now if you upgrade your svn client again, Xcode will magically be upgraded. The downside is that if you end up upgrading your Xcode you will have to go through this process again.

I got this information from a blog called “Tommy’s Domain” and decided to digest it here.

XCode’s (in)ability to effectively link static libraries

We all love developing for IOS and Mac. Yay. Ra, ra, sis boom bah. If you do a lot of different projects, you start to realize that some of the stuff you do is repeated in each project. So you think you know how to deal with this in an effective manner and say to your self, “I need to create a library out of this code so that I can re-use it in all my projects”.

The instinct now-a-days is to create a dynamically linked type of library, so, a framework, but you can’t do that for IOS, and I don’t like them anyway because there is a chance that when the user installs a new app that has a newer version framework or DLL, an already installed app might break due to a possible incompatibility. You have to worry about backwards compatibility when you have more than one app on the same system using it whereas with a static library you don’t. A good developer would verify that the new dynamic library is fully backward compatible. A good developer also wants to ensure that their apps play nice in the user’s system, and the best way I think to play nice is to eliminate any risk of breaking other parts of the user’s system. I’m weird that way.

I prefer, and IOS requires, statically linked libraries. The linker is smart enough to take the functionality that your app requires and link that in from the static library, and discard the rest of the static library. That’s how it is “supposed” to work. Objective C employs dynamic symbol binding, allowing you to modify classes at run-time. This unfortunately makes it much more difficult for the linker to know what to link in and it ends up failing miserably. For example, from my observations, if you put a class category in a static library, it won’t get linked. If you include a file in a static library that ONLY gets used by other files in that library, the code in that file won’t get linked.

Apple’s Technical Q&A QA1490 describes how one is to get around this problem. The solution involves adding some linker flags to change the way that the linker behaves in regards to what code to not link. If you add -ObjCto your project’s ‘other linker flags’, the linker will the always link all Objective C classes and categories without considering if they are used by the project. This is the main solution, and should completely solve the problem (while unfortunately making your executable larger), however, apple admits to a bug in their linker when working with 64 bit or IOS code where this flag is unable to link static libraries that contain only class categories. To solve this, you must also include the -all_load flag. This flag instructs the linker to not discard anything. All the library contents will be linked all the time. This solves the linker bug, but makes your executable even larger still.

In the stackoverflow question: What does the -all_load linker flag do? a comment to the answer asked why there wouldn’t be some warnings or errors at compile time for the missing methods. Sophistifunk answered that question as follows:

No, because the categories exist at compile-time, they’re just not being linked into the final binary. But because of the dynamic nature of Obj-C dispatches, the linker doesn’t point calling code directly to the implementing method, so it never notices that it’s missing. Then at runtime, you get the kaboom, the same as if you’d called it using “-performSelector:” – Sophistifunk Jul 23 ’10 at 4:09

So the solution? always include -ObjC when linking static libraries with Objective C code, and if there is a library that ONLY contains categories, and no actual classes, also use the -all_load flag.

1and1 MyWebsite and Widgets

I really like the MyWebsite feature that I got with 1and1, but there are definitely limitations. If I want to embed something from some other website, like say a like button from Facebook, that embed code MUST be XHTML compliant. If not, 1and1 strips out the bits that are not compliant and you are left with a mess that doesn’t work. Luckily there are several social apps that can be put on your site,, including a Facebook like button, but these are not always configurable enough, and they certainly do not have all the stuff I would like to use. For example, if you have a UserVoice account, you’re out of luck. There is no 1and1 app for that, and the embed code is definitely not  XHTML compliant. Perhaps I need to see about creating my own 1and1 apps. It’s either that or change to a web hosting plan, which would let me do all the stuff I want, but would also dramatically increase the  amount of time it would take me to get it done.

Single Bundle Apps

As seen on StackOverflow here,

The question:

Archiving my project in Xcode is creating a multi-application bundle, instead of bundling my main target for release, which is what I want. Specifically, when I validate my archive in Organizer, it gives me the message:

“[projectname] does not contain a single–bundle application or contains multiple products. Please select another archive, or adjust your scheme to create a single–bundle application.”

The answer by Ryan Grimm:

Two things needed to be fixed in the sub-project(s) to resolve this issue:

1As Jared discovered, under the Build Settings, set the “Skip Install” to “Yes”Under the Build Phases, examine the Copy Headers section.

2If there are any header files listed as Private or Public, drag them down to the Project section.

C++ Builder + FireMonkey = Mac Apps

Embarcadero enables you to write software for the Mac using it’s C++ Builder and Delphi tools in Windows. This is very awesome. They even enable you to debug your applications right on a Mac, through your IDE. The way this works is that they require you to install a tool on your Mac Called PA Server (Platform Assistant Server). All communication between your IDE on the Windows machine, and your test app on the Mac happen through this tool.

This is very cool, except that it is a command line tool and so you have to do a little work to get it started, and I am just far too busy for that (read lazy 🙂 ), so I made a little GUI wrapper for their tool. You can find it here.