standard way to require c++11?

[Mojca Miklavec]

On Wed, Apr 15, 2015 at 9:42 AM, Mihai Moldovan wrote:
> On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
>> Yes, I actually have libc++ on all of my SL+ machines except a couple
>> VMs I keep around for testing the default configuration.  IMO, it
>> seems far easier to live on libc++ on SL than libstdc++ because so
>> many ports these days require it.
>
> What are they actually requiring? libc++ or C++11? I don't know any port
> that fails to build with libstdc++ but is happy with libc++ offhand.

That was probably a question for Jeremy, but my guess is "C++11". And
using libc++ is simply one of the easiest way to provide "native"
support for C++11 (maybe with less crashes than if using GCC 4.9; and
certainly with more "caring love" from Apple developers that are
"forbidden to touch GPL 3").

>>> No, libstdc++ is explicitly designed to allow multiple,
>>> incompatible libstdc++ version being in use at the same time.
>
> On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
>> I think you misunderstand.  This is not entirely true.
>
>> Why do people report problems then?
>
>> Because the above is completely entirely true.  You can have multiple
>> versions of C++ runtimes in the same process (even libc++ and
>> libstdc++).  The issue arrises when you try to pass objects between
>> them.  For example, assume libA links libstdc++ and libB links
>> another copy of libstdc++ as well as libA.  If libA exports C++ API
>> that libB consumes, then it will be interacting with them through the
>> wrong runtime.
>
> Re-iterating: is this not the case for multiple copies of libc++?

I don't know enough to answer, but at the moment we don't have
multiple copies of libc++ anywhere. (Yet. I'm not sure what C++1z will
bring.)

>>>>> In my experiments with a 10.6 VM, mp-clang-3.4 -std=c++11
>>>>> -stdlib=libstdc++ chokes on #include <type_traits>.
>>>>
>>>> I would suspect some misconfiguration. I successfully compiled
>>>> many C++11 projects with mp-clang-3.4 (and libc++ of course).
>>>
>>> On OS X lower than 10.9? I can take out my VM for a test spin
>>> "tonight" and see if I can reproduce the issue (as a "minimal
>>> testcase" without MacPorts.)
>>
>> Maybe I didn't express it properly (or maybe I didn't read your
>> statement carefully enough in the first place). Yes, you can compile
>>  "#include <type_traits>" on < 10.9 with clang++-mp-3.4, but not with
>>  the system libstdc++ and I'm not sure how you would compile against
>>  libstdc++ as shipped by libgcc/gcc-4.9.
>
> Ok. We have a consensus here. clang and libstdc++ on < 10.9 doesn't work.

True.

> This problem could probably be solved by
> patching clang (but it's not elegant or very sane.)

I wouldn't dare even attempting anything in that area.

> On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote:
>> 'sudo port -v -s install libcxx' is fairly automatic ;)
>>
>> If you want to configure MacPorts to use the compiler by default,
>> that isn't automatic but is fairly easy with steps laid out at:
>> http://trac.macports.org/wiki/LibcxxOnOlderSystems
>
> It is not. A user must edit macports.conf multiple time while
> bootstrapping the MacPorts system for libc++, (re-) build clang/llvm
> ports multiple times to make them use the correct stdlib, will not be
> able to use binary archives etc.

This is only true for 10.5. It works automatically on 10.6 and later
as soon as the user changes three lines in macports.conf (before
installing anything). The complicated bootstraping procedure is only
needed for 10.5. 10.6 and later is a piece of cake.

(It would also be nice if someone could provide "bootstrapped" version
of MacPorts for 10.5 with all the binaries that are needed to continue
from there.)

> The needed compile time alone is inconvenient for users. And users will
> need to actually *know* about having to change options and maybe even
> re-compile all ports/bootstrap somehow. My goal was to provide C++11
> support transparently, without needing to change the macports.conf or
> rebuilding the whole system.

Of course we need to solve two different problems:

(a) Trying to patch the ports just enough to allow users to use C++11
software on "default" MacPorts installation with libstdc++. Taking
into account all the limitations.

(b) I've been suggesting for a long time already that we should set up
three new buildbots to build packages against libc++ on 10.6-10.8. The
lack of a buildbot is a showstopper for me, preventing me from
globally switching to libc++ (on an old OS). And as more and more
software is now shifting to C++11, the situation will just get much
worse with time. If we start supporting libc++ in such a way that:
- buildbots will build packages against libc++
- users will be able to download a pre-configured MacPorts dmg
(including the proper configuration)
then it will no longer be a problem for users to switch to libc++. Of
course that doesn't mean turning off the old buildbots right away. We
need sufficient testing first and we'll certainly need quite a bit of
adapting of the Portfiles before we are able to provide a smooth user
experience.

If you are trying to address (a), that's still a very valuable effort.
I was just pointing out that some of your assumptions (like inability
to use clang) were not entirely correct.

> - There is no way to transparently provide C++11 support on OS X < 10.9.
> Users will need to switch their MacPorts installation to libc++ by
> rebuilding all ports.

Yes and no. In principle it's possible to switch to libc++ on per-port
basis (in the same way as you switched to GCC), but that gets
complicated when dealing with dependencies. I created a port
wxWidgets-3.0-libcxx just to be able to compile a few C++11 GUI
programs like FileZilla. But that's just "patching" that has its
limitations somewhere. Sometimes it works, but you are just lucky if
it does and if no dependencies clash. Some ports switch to GCC instead
and hope that dependencies won't clash with each other.

It would be better if users had a chance to switch to libc++ for a
complete installation.

> - Even doing that may lead to situations where C++11 is used but also
> Apple's libraries or frameworks linked at the same time. If libstdc++ is
> being (implicitly) linked by that, linking fails. These ports will be
> uninstallable on a pre-10.9-libc++ system.

I don't know enough to confirm that behaviour on a particular port,
but it is certainly possible that it's true. A more problematic aspect
of that approach is that users might install certain libraries (like
libpng, wxWidgets, ...) and then try to build their own software (like
gnuplot) against libraries in MacPorts without switching to libc++. So
users installing the libc++ flavour of MacPorts would have to know
what they are doing.

> - Following my original idea of using libstdc++ on pre-10.9 systems will
> potentially link different versions of libstdc++ at the same time and
> not lead to linker errors, but most likely crashes or other undesired
> behavior at run time.
> - OS X >= 10.9 is fine regarding C++11.
> - C++14 support comes "free of charge" on 10.9 and 10.10 with XCode 6
> and if using MacPorts' libc++ and clang-3.4 or higher on 10.8 and below.
>
> That doesn't sound too nice.
>
> I have to add yet another thing, though. We'll be running into a similar
> issue on 10.9 and 10.10 (and (10.10)++ and ...) once C++1z (the next
> standard) is released and gains widespread usage. How can we provide
> C++1z support, if the system libc++ does not? Install our own version of
> libc++ and rebuild MacPorts against that?
> At some point, this will *also* lead to using different libc++ runtimes.

Don't open another can of worms ;) We have enough problems already.
It's probably good to keep those future problems in mind, but we
should solve the current problems first.

Mojca