C++11 on Mountain Lion and lower?

Clemens Lang cal at macports.org
Wed Dec 4 16:22:42 PST 2013


On Wed, Dec 04, 2013 at 03:46:49PM +0100, Clemens Lang wrote:
> Of the system libraries in /usr/lib/system, only a single one exports
> C++ symbols (and that seems to be related to kernel extension stuff).
> I haven't checked for the libraries in /usr/lib, but I'll try to come
> up with a shell script to look for C++ APIs in those libraries
> tonight. dyld is implemented in C++, but I think it only exposes C
> APIs.

I've done that and found only 4 libraries in /usr/lib export C++ APIs
(tested on 10.9):

 - libcupsppdc.1.dylib (what is this anyway?)
 - libhunspell-1.2.0.0.0.dylib (present in MacPorts)
 - libicucore.A.dylib (present in MacPorts)
 - libmecab.1.0.0.dylib (only a few symbols, what is this?)

So in conclusion using a C++ runtime different from the one the host
system uses might be a doable solution because these are the only
libraries users would have to avoid.

So remaining questions:
 - Which C++ runtime should be used? Host libc++? A newer libc++ from
   MacPorts? How can clang be convinced to use that?
 - Do we have the manpower to pull this off and support it?

To be honest, I think the last question needs to be answered with "no"
and might kill the whole idea. At least we have some data on how
"dangerous" it is to use trunk and change cxx_stdlib to libc++.

-- 
Clemens Lang



More information about the macports-dev mailing list