Host Versus MacPorts lib[std]c++ [was: Re: Fortran recipe]

Michael Dickens michaelld at macports.org
Thu Aug 29 07:12:02 PDT 2013


On Aug 29, 2013, at 12:58 AM, Jeremy Huddleston Sequoia
<jeremyhu at macports.org> wrote:
> The problem is that more and more ports are going to be requiring C++11 features which means they will require a runtime that supports it (that is either MP's libstdc++ or libc++).  MP's libstdc++ is out of the question as far as I'm concerned, so that leaves libc++.

OK; I get that you cannot touch GPLv3'd code, which includes the sources
for GCC and libgcc, and thus libstdc++ which is part of libgcc -- these
can taint you, and are thus out of the question.  libc++ is code that
you can touch, as well as, I'm guessing, the code for clang and llvm. 
I'm sure there are other MP developers who also cannot touch GPLv3'd
code, but I'd bet there are plenty who can.  Given that MacPorts is
supported/blessed at least in part by Apple, and Apple is moving away
from GCC towards Clang/LLVM, it makes sense for all of MacPorts to
follow this transition as robustly as we can.

On Aug 29, 2013, at 12:58 AM, Jeremy Huddleston Sequoia
<jeremyhu at macports.org> wrote:
> Our ports are not "using libstdc++" they're "using the C++ runtime selected by the C++ compiler". The switch to libc++ on Lion and ML is as simple as setting configure.cxxflags to contain "-stdlib=libc++" when the compiler is clang, revbumping all the C++ ports, and dealing with fallout in ports that don't support libc++.  That's something I've been doing on and off for the past couple years anyways, and we're fairly close (at least for the ports I use).

On Aug 28, 2013, at 6:06 PM, Jeremy Huddleston Sequoia
<jeremyhu at macports.org> wrote:
> One option is to have the gccXX ports use 'clang -c -x assembler' instead of as.

A quick search for clang being explicitly blacklisted shows around 175
ports out of roughly 17500 total ports; roughly 140 explicitly blacklist
some form of gcc. Not all of these ports use C++, and some are probably
unmaintained/obsolete and can thus be dropped, which drops the total %
somewhat below 1% for either category. Hence, it is fair to believe that
the vast majority (some 99%) of all MacPorts ports can use clang or gcc
interchangeably, and hence can the vast majority can also use libc++ for
the C++ runtime library.

Given the prior discussion and the above: It seems to me like creating a
branch (like what Mojca just did for the WX stuff) that sets
"configure.cxxflags-append -stdlib=libc++" when compiling with clang,
and "AS='clang -c -x assembler'" (or, whatever works) when compiling
with GCC would be an interesting experiment.  Those of us interested in
having a common C++ runtime could contribute to it, try to get as many
ports as possible tested and working with this methodology.  If we're
not going to shoot for a common libstdc++ (for any reason, not just
because certain developers cannot touch that code), then I'm all for
shooting for a common libc++ -- and, sooner is better than later IMHO. -
MLD


More information about the macports-dev mailing list