C++11 on Mountain Lion and lower?

[Chris Jones]

Hi,

> On 5 Dec 2013, at 12:22 am, Clemens Lang <cal at macports.org> wrote:
> 
>> 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?

I guess a version of libc++ from MacPorts would have the advantage it would allow the use of a complete c++11 implementation on systems where the host version is lacking. Could this be done by just making one of macports own clang compilers the default compiler... ? 

> 
> 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
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev