C++11 on Mountain Lion and lower?

[Titus von Boxberg]

Am 04.12.2013 15:46, schrieb Clemens Lang:
> 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.

You describe my use case very well.
At no time have I been frustrated, even though I had to climb
into my own learning curve some time ago:

http://permalink.gmane.org/gmane.os.apple.macports.devel/14693

And that was only about intermixing two different libstdc++.

Immediately afterwards, I decided to compile my own versions of
the libs I require.
And in such a case one has nicely maintained portfiles
to use cmd-c/cmd-v. "Lost" is a hard word for that situation:
In my opinion that's not too much work for a C++11 developer sticking
to os versions nowadays already dying out.

Again: I don't want to object or anything else if someone does find
the time to get C++11 right for older OSX versions.
I'm only saying: I'd expect that to be rough, and
less and less nessecary due to the phase out of older OSX.
(Around June 2011, my thinking would have been the opposite ;-)

For a cheaper idea to keep error reports low, what about
wrapping MP's g++ and clang++ in a small warning banner program?
It could print a message like:
"do not link to macports c++ libraries with this compiler"
if the macports C++ runtime isn't the same as the one of the
compiler being invoked.


>>> 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.)

It's OK as long as every part of the final software uses the same C++ 
runtime and no other ABI break is introduced (I don't know of
an example).

And for the reasons outlined earlier, if the decision is made to
provide an own runtime with macports, I would try to make that libc++
provided by (macports) clang.

So I'd recommed to drop support for ports strictly requiring g++.
As far as I understood from the 10.9 discussions on the list
this is currently done by macports for 10.9, anyway
(just because macports has to stick to clang++ on 10.9).

Regards,
Titus