I have a software that compiled with libc++ (LLVM C++ standard library with C++11 support). My software works good on new operation systems (os x 10.9 and above). The problem is that my software crashes on old operation systems (os x 10.8 and below). I think it because the default C++ runtime on OS X 10.8 and earlier is a version of libstdc++ based on GCC 4.2.1 which does not support C++11. What can I do?
-
2It *crashes*? That usually points to things beyond an outdated runtime... – DevSolar Feb 16 '16 at 09:58
-
DevSolar, every time it crashes on a different location. Must of the time on malloc function. – Ofer Feb 16 '16 at 10:01
-
t.niese, Yes I create the project with Xcode. I'm using base SDK: "OS X 10.8". – Ofer Feb 16 '16 at 10:03
-
2That it *runs* in the first place, and crashes at various points, *definitely* hints at undefined behaviour that just happens to be exposed on the older OS version. If the runtime were incompatible, the program would fail to load / run, full stop. You should find and fix the error(s) in your code. – DevSolar Feb 16 '16 at 10:04
-
2Sorry delete comment instead of editing. The problem might not be the c++ version itself but the used version of the standard library. `libstdc++` and `libc++` are not fully binary compatible, if you compile your application against `libc++` and dynamically link against a library using `libstdc++` then your application might crash unexpected if you pass e.g. an `std::string` between them. – t.niese Feb 16 '16 at 10:09
-
t.niese, what can I do about it? – Ofer Feb 16 '16 at 10:53
-
1The depends, make sure that you don't pass complex objects like std::string between the libraries, if you need to do that you either need ship the dynlib compiled again the same stdlib as your application with your application or you need to static link against the lib. – t.niese Feb 16 '16 at 11:02
-
The crashes are in libs like: libsystem_c.dylib, libobjc.A.dylib. Can I ship with a version of them that compiled again libc++? – Ofer Feb 16 '16 at 11:26
-
The place where the crash happens does not necessarily need to be the origin of the problem. If you e.g. pass a `std::string` between two non binary compatible peaces of code and the string is modified in both of them, then a memory corruption might occur which then might later result in a crash at any other point. Without knowing the code and the setup of your project it is nearly impossible to give you a solution. And it this might also be out of the scope of SO. – t.niese Feb 16 '16 at 12:09
2 Answers
You might try to link your software statically (perhaps link only the C++ standard library statically, and the libc
dynamically).
Otherwise, like on most POSIX systems, you could try to install the old OS in a chroot
-ed environment of your new OS.
You could also try to compile the new standard C++ library for the old OS (perhaps using cross-compilation tricks).
BTW you should compile your code with all warnings and debug info (so clang++ -Wall -g
and/or g++ -Wall -Wextra -g
). Improve your code till you get no warnings. Use recent compilers (e.g. GCC version 5, Clang/LLVM version 3.7 at least), the debugger (gdb
), valgrind, the Address Sanitizer, etc. Be very scared of undefined behavior (it smells like your code might perhaps have some UB).
(you could compile recent compilers and other free software tools from their source code)

- 1
- 1

- 223,805
- 18
- 296
- 547
-
This isn't a concrete answer, it's a bunch of comments splurged together. – Puppy Feb 16 '16 at 18:31
-
That's my favorite kind of answer :D ----- In seriousness, to expand upon "you could compile recent compilers from their source code", a relatively simple way to do that is using homebrew, which can build gcc from source in a fairly painless manner – Chris Beck Feb 17 '16 at 05:23
In xcode you can set OS X Deployment Target to the minimum version you want in
Project-name (1) -> Build Settings (2) -> Deployment Target (3)
And verify further down that dialect it set correctly in
Apple LLVM 7.0 - Language C++ -> C++ Language Dialect -> C++11

- 6,536
- 6
- 41
- 51