clang, libc++, libc++ABI & MacOSX 10.6

I have a feeling Howard might be the person to discuss this matter, but I'll throw it out here for everyone. I'm sure it is a discussion that would draw interest from other mac developers.

I'm working on transitioning our codebase to C++11. The problem is that we still have to support 10.6 for another couple of years at least. I got this wild idea that perhaps I could deploy c++11 code to 10.6 by building the latest versions of clang & libc++ on 10.6. I got clang built. I got libc++ to build as a static lib. I got libc++abi to build as a dylib. I was able to build and run a test program with c++11 STL code on 10.6. Test successful.

HOwever, I have a few questions before I invest any more energy in this:

1) If I start using the frameworks and libs in the 10.6 SDK to build full-blown mac applications, am I going to have problems with mixing two std library implementations in a single process?

2) I'm using the latest code for all the projects. Is this software stack reliable and production-quality on 10.6? I don't have the expectation that Apple would support using the tools on 10.6, but I'm just asking in terms of what you know about the innards of the technologies involved.

3) Am I going to have any limitations on the C++11 functionality on 10.6? For instance, based on previous conversations on this list, I don't expect 'thread_local' to ever work on 10.6. Are there any other such features that have no chance of working on 10.6?

4) Since we are a developer of commercial desktop apps, I prefer to use static libs to avoid giving the customers the ability to break the app. On OSX, a dylib wouldn't be a deal-breaker given I could load it in the app's bundle, but I'd still prefer the static libs if possible. I built libc++abi as a static lib, but I'm finding that I get number of duplicate symbol errors when I try to link both libc++.a and libc++abi.a with an executable program. Clearly, I have to merge the two libs. I have not attempted to do any analysis yet on the functions, but I suspect the libc++abi duplicated functions are going to be identical to what is in libc++. Is this true? Do you foresee any problems with deleting one set of the duplicate functions in one of the libraries?

-James

I feel you pain. :-\

I know of no reliable way to use libc++ prior to 10.7.

I would be surprised if exception throwing across dylib boundaries (libc++/libstdc++) worked on 10.6.

If you ship static or dynamic versions of libc++/libc++abi, the likelihood of breakage is strong, especially with exception throwing and dynamic_cast. libc++abi especially is designed to be the only C++ exception catching mechanism in the process.

About the only thing that I imagine might work is using a template from libc++ headers that you know to be completely instantiated into your code with no dependence whatsoever on libc++.dylib. You may need to toggle-off the use of "extern template" in libc++ headers to do this.

Howard

bummer. that's why I asked before I spent more time on it. The time spent so far was worth the education.

thanks!

Hello,

1) If I start using the frameworks and libs in the 10.6 SDK to build full-blown mac applications, am I going to have problems with mixing two std library implementations in a single process?

As long as you only use C- or Objective-C-based frameworks and libraries, in my opinion you should be
good to go, as they won't use the C++ standard library. I am using Cocoa, OpenGL and some other
frameworks plus 10.6's libiconv in my application together with libc++ on 10.6 without a hitch.

Mixing libc++ and libstdc++ on the other hand *will* result in problems. In fact I just spent several
hours yesterday tracking down a crash that resulted from me accidentally linking against libstdc++
(it was exception-related).

3) Am I going to have any limitations on the C++11 functionality on 10.6? For instance, based on previous conversations on this list, I don't expect 'thread_local' to ever work on 10.6. Are there any other such features that have no chance of working on 10.6?

I cannot comment on thread_local as I haven't had any use for it and according to the status page clang
doesn't even support it (yet), but I've been using clang, libc++ and C++11 on 10.6 for several years now
without any problems (modulo above crash). Generally speaking, functionality that doesn't require specific
OS support should be no problem.

HTH,
Jonathan