standard way to require c++11?

[Jeremy Huddleston Sequoia]

> On Apr 14, 2015, at 00:11, Mojca Miklavec <mojca at macports.org> wrote:
> 
> On Tue, Apr 14, 2015 at 8:18 AM, Mihai Moldovan wrote:
>> On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
>>> On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan wrote:
>>> Could something like that be added to the compiler_blacklist
>>> PortGroup? I believe that pure C++11 projects need consistent handling
>>> and it would be very handy to allow a keyword like "compiler.c++11" or
>>> "compiler.<something> c++11" to replace all of the logic above inside
>>> a port.
>> 
>> Yes, I should make that a PortGroup, iff it turns out to be good enough
>> to be one.
> 
> In my opinion this could/should be part of compiler_blacklist. No real
> need for a separate PortGroup.
> 
>>> I don't fully understand that part. What if someone sets libc++
>>> globally? And: won't that pull in libstdc++ from gcc?
>> 
>>> = 10.9: libstdc++? error
>>> = 10.9: libc++? continue
>> 
>> <= 10.8: libstdc++? continue
>> <= 10.8: libc++? error
>> 
>> This by itself is not pulling in anything yet. What I wanted to express
>> is that I assume using libstdc++ on >= 10.9 an error and using libc++ on
>> <= 10.8 an error.
> 
> While I do understand "10.9: libstdc++? error", I disagree with "<=
> 10.8: libc++? error" for at least two reasons:
> - A bunch of my ports explicitly switch to libc++ (just because they need C++11)
> - Users can set to use libc++ globally
> 
>> If someone on <= 10.8 set libc++ globally... tough luck. He'll get an
>> error when trying to install the port.
> 
> Which is stupid. Users would set libc++ globally precisely for the
> reason you are trying to address: to avoid issues with the lack of
> C++11 support in libstdc++. And then you are ruling out exactly the
> users who care about C++11 most.

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.

>> But given that, in the case of
>> hardcoding configure.cxx_stdlib to another C++ runtime than the
>> autodetected/default value, the selected C++ runtime not matching the
>> system C++ runtime and this potentially leading to a variety of subtle
>> to not so subtle bugs, erroring out looked like the best thing to do.

What do you mean by "the system runtime"?  There is no "system runtime".  There are two runtimes available on the system, an ancient libstdc++ kept around for binary compatibility, and a more modern libc++.

> Jeremy did extensive testing of that configuration and I'm running a
> copy of MacPorts with those changes as well. I hardly experienced any
> problems (other than initial build failures that had to be polished
> out every now and then). I believe that this should become the default
> setting in not too distant future if we want to keep MacPorts working
> on older systems.

To be fair, I did most of the work in MacPorts only after extensive testing of the configuration and transition by Apple in Mountain Lion (or maybe it was Mavericks).  On newer OSX versions, we have an added benefit of having libstdc++ on top of libc++abi.  We don't have that benefit on SL, but other than that, installing the libcxx port on SL gets you a pretty modern and well tested C++ runtime that is forwards compatible with the system libc++ on Lion and later.

>> No, libstdc++ is explicitly designed to allow multiple, incompatible
>> libstdc++ version being in use at the same time.

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.

>>>> In my experiments with a 10.6 VM, mp-clang-3.4 -std=c++11
>>>> -stdlib=libstdc++ chokes on #include <type_traits>.

Yeah.  That's because C++11 isn't supported by libstdc++ on SL.

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

See http://trac.macports.org/wiki/LibcxxOnOlderSystems

> 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. But the idea is that you *can*
> compile that if you use libc++. My main point was that there should be
> no need to blacklist clang.
> 
>> cat test.cpp
> #include <type_traits>
> 
> int main()
> {
> return 0;
> }
> 
>> clang++-mp-3.5 test.cpp -o test
> test.cpp:1:10: fatal error: 'type_traits' file not found
> #include <type_traits>
>         ^
> 1 error generated.
> 
>> clang++-mp-3.5 test.cpp -o test -stdlib=libc++
> [success]
> 
> 
>>>> Hence, I blacklist all clang versions on 10.8-.
>>>> 
>>>> This will leave us with quite a mess. Now all compilers are blacklisted
>>>> on older systems. Great.
>>>> 
>>>> Not a big deal, though. We can set compiler.fallback to macports-gcc-4.9
>>>> and port will use this specific compiler, given all others are blacklisted.

Uh.  No.  Using macports-gcc for C++ code will lead to using the libstdc++ installed by the libgcc port.  Thus, that code won't be shippable without also shipping the C++ runtime, and it won't be compatible with projects wanting to use either of the system C++ runtimes.  Using macports-gcc for C++ code is really the worst option, IMO.

>>>> With that, compiling C++11 code on 10.8- works great (I've tested it in
>>>> a 10.6 VM) -- and the binaries even run correctly.
>>> I still believe that if the code was moved to a PortGroup, one would
>>> have to allow building with clang against libc++.
>> 
>> Maybe... I mean, coupled with Jeremy's efforts getting libc++ to work on
>> 10.5 and 10.6.
> 
> It already works (perfectly) on 10.6. His recent efforts were
> addressing 10.5 and I'm not sure if the work is finished by now, but
> yes, 10.5 might be doable.

I haven't really looked at it since the winter holiday.  The main bug blocking libc++ on Leopard is a bug in libunwind https://llvm.org/bugs/show_bug.cgi?id=22270

>> That procedure isn't exactly automatic, though.
> 
> It is on 10.6.

'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

>> And even
>> then -- won't you be mixing libc++ and libstdc++ when linking anything
>> system-related that happens to be written in C++ and links libstdc++?
> 
> In your case one would be mixing libstdc++ shipped by apple and
> libstdc++ as shipped by gcc. From what I understand from fellow
> macports developers/maintainers mixing different libstdc++ is worse.

It's worse only in that it's less obvious.  If you screw up accidentally mixing libc++ and libstdc++ binaries, you'll get a linker error.  If you screw up mixing two different libstdc++ based binaries, you'll probably link ok since the symbol mangling will be the same, and you'll only notice odd errors at runtime.

>> My idea is: stay with libstdc++ on "legacy platforms" and avoid the
>> problems created by mixing C++ runtimes, messing with user systems in a
>> non-interactive way and creating a new buildslave infrastructure. Why
>> would you not use libstdc++, if it works *and* can be used -- together
>> with GCC -- to compile C++11 code?

It can't.  You'd be using *differnet* libstdc++ runtimes.

Also, libc++ is the default on newer OS versions, so why not just use it and be compatible?

>> (Yes, I'm avoiding your "PPC
>> problem". I'm seriously sorry GCC is not building there, but there's not
>> much I can do about that.)
> 
> I wasn't talking about PPC here at all (and I believe that gcc
> actually compiled successfully in the meantime***). We are still
> talking about 10.6-10.8 with x86_64.
> 
> Mojca
> 
> *** I tried to debug a piece of software (luajit), but it keeps
> crashing occasionally even after being compiled with gcc 4.9 on 10.5
> ppc, so I gave up on that particular problem until I meet with a
> couple of other hackers who might be able to help with the issue.
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4109 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150414/1bad3e26/attachment-0001.p7s>