C++11 on Mountain Lion and lower?

[Clemens Lang]

On Wed, Dec 04, 2013 at 02:52:02PM +0100, Titus von Boxberg wrote:
> you dropped the last text block from my mail where I said that I think
> that macports shouldn't care much about users using macports libraries
> for their own software.
>
> This is why also in your mail quoted below in my opinion these things
> get mixed up: you mix up users of macports executables with developers
> using macports libraries.

Well, I disagree with you on this. Building libraries you need for your
own software _is_ a relevant use-case for MacPorts, and I don't think we
should disregard it.

I wouldn't even differentiate between "users" of MacPorts executables
and developers using libraries from MacPorts. I'd even assume most users
that use the command line and MacPorts extensively *are* in fact
developers.

> Again, only as a recommendation:
> macports shouldn't care about this "c++11 library use case"
> (if it's not cheap, and I guess that it wouldn't be).

It's not trivial, but we haven't decided yet whether it's impossible to
get right -- that's what we're discussing here.

> Developers wanting to use C++11 should be using 10.9. As said, (only)
> on this system, using clang from xcode 5, it comes with (almost) no
> extra cost for macports to have the whole port set moved to a c++11
> compliant runtime (which reenables C++11 developers to use the
> libraries compiled by macports for their own software).
> 
> C++11 developers really targeting earlier systems then are on their
> own. And spoken from my experience, they aren't lost since macports
> already provides compliant implementations also for systems < 10.9. I
> simply wouldn't spend the time to make it use them for its own
> purposes (that is, the executables it compiles).

They are lost if they need to link against a C++ library, e.g. boost
compiled against a runtime that supports C++11. And these libraries are
probably the reason they were trying to use MacPorts in the first place.

Consider a developer who wants C++11 support on 10.8. He might find out
that he can use libc++ (from MacPorts or from the host) and clang. Then
he tries to use boost, tries to use the MacPorts version and experiences
weird crashes, because MacPorts boost is compiled against libstdc++.

Sure, we could just tell users that's unsupported, but that will only
cause frustration at best. Especially if there is a way to make this
work correctly.

> Basically, all this boils down to following recommendations:
> - tell c++11 developers to use 10.9+Xcode 5
>   (presumably, they will know already).
> - mark all ports requiring the new runtime as unavailable
>   on systems < 10.9
> 
> Some smaller comments below.
> 
> Regards,
> Titus
> 
> I'm using only the Darwin / POSIX subset of MacOS together with Qt or
> wxWdigets, so I don't know.
> Does OSX really offer (so many) C++ APIs?

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 doubt but don't know whether there are any other C++ libraries
> >>   in /usr/lib (besides a stone old implementation of wxWidgets on 10.6)
> >>   Using them within macports would collide with the macports
> >>   philosophy not to use more of the base system than necessary.
> >
> >Yes, but as I said, MacPorts building its own ports is not the only
> >issue here, users trying to build their stuff is just as relevant.
> 
> Why "yes"? Did you mean "no"? Otherwise this contradicts what you said
> above. Or are you intermixing C and C++?

"Yes" was referring to "using them within MacPorts would collide with
the MacPorts philosophy".

> >>- currently, there might still be some ports that require g++
> >
> >Which is fine as long as they don't any C++ API (we all know that, but
> >just as a reminder).
> 
> I really meant "g++" (to compile C++). That always uses C++ API/ABIs.
> I didn't mean the ports that require the C (or even the FORTRAN) part
> of gcc.

Yes. Compiling with g++ (and thus using MacPorts libstdc++) is fine, if
the compiled library does not expose a C++ API, isn't it? (Sorry, it
seems I forgot the word "expose" in this sentence.)

> >We don't need long-term support, because it's obvious that on systems
> >that use libc++ as default runtime we're going to use that. The question
> >we're facing is what to do on systems that still use libstdc++ as
> >default runtime. clang can compile against libstdc++ just fine and if we
> >can convince it to compile against MacPorts libstdc++ that would be a
> >viable solution, IMO.
> 
> Again, I don't know. But I really doubt that you could convince
> clang++ to offer a fully compliant C++11 implementation when using any
> version of libstdc++. I would try to not even think about that since
> it's nonstandard (at least for Apple).
> 
> As said above: since libc++ is - from 10.9 onwards - the only
> officially supported implementation macports really should stay with
> it.

A good point and a good reason to use libc++, if anything.

> >Which would also mean not supporting C++11 on systems < 10.9. As I
> >mentioned before, we've had users ask for C++11 support on these systems
> >and I think there is a need for that.
> >
> Again: Where is the need coming from? From within macports
> (executables) or from users of C++ libs compiled by macports.