Hi, > On 5 Dec 2013, at 12:22 am, Clemens Lang <c...@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@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev