Hi Clemens, all,
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.
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).
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).
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
Am 04.12.2013 12:29, schrieb Clemens Lang:
Hi,
libc++ has been available for a while now, but was not the default. I
think it was first shipped in 10.6(?), although the older versions
probably have their own set of problems related to compiling C++11 code.
- I don't see what the question of C++11 support and thus
the c++ library version has to do with the OSX version besides,
presumably, that 10.9 is the first OSX release with full (?) C++11
support in the preinstalled C++ standard library.
macports provides two recent C++ implementations, clang/libc++ and
FSF g++, that both work on systems earlier than 10.9
It does matter in the sense that OS X ships a number of libraries that
export a C++ API. The runtime these libraries use should also be the
runtime MacPorts uses for all its own stuff, because while we can avoid
using them in our ports, we might not be able to stop users from using
them and libraries built from MacPorts in their own software.
A question that still remains is how many of the libraries shipped with
OS X actually offer C++ APIs. If there's only a few minor libraries we
could disregard the compatibility problem here, document that those
shouldn't be used when linking against libs from MacPorts and choose a
C++ runtime independent of the system-provided one. That would solve our
C++11 issues, because we could either use a recent (MacPorts-provided)
libc++ or a recent (MacPorts-provided) libstdc++ for C++11 support (and
thus also for _all_ other ports).
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?
- 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++?
- 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.
How many C++ ports really require something newer than gcc 4.2.1?
Are they used by many macports installations?
How does the estimated growth rate of these ports relate to
the estimated phase out rate of older OSX installations?
In short, how bad is the pain to drop the idea of C++11 on OSX < 10.9?
And the other way round:
Down to which OSX version shall macports be responsible for providing
a recent C++ runtime and how much effort should that take?
That's the right set of questions. Unfortunately I don't have an answer.
At the moment it seems to me C++11 on systems < 10.9 is going to be a
feature ports (and users!) will request. If I remember correctly there
have been a number of questions on how to compile C++11 code on these
systems, even before we discussed the runtime mixing problem on this
list.
I don't know macports well enough to answer these questions,
but here are some guesses trying to be educated:
The only C++ runtime on osx that I'd expect to have long term support
is clang/libc++. Then I'd first rule out using a newer self-built g++
since that collides with the reasons to use clang/libc++, anyway.
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.
My second guess is that I'd drop the whole idea of macports providing
its own C++ implementation ;-)
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.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
