standard way to require c++11?

[Mihai Moldovan]

On 14.04.2015 07:44 AM, Mojca Miklavec wrote:
> On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan <ionic at macports.org> 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.


>> -------------------------------------------------------------------------
>>
>> Human-readable explanation:
>>
>> I've added the compiler_blacklist_versions PortGroup and blacklisted GCC
>> < 4.6 and clang < 3.3, as only newer versions than that are fully
>> C++11-compatible for all platforms.
>>
>> Then, I'm patching out -lc++ added by upstream for not very smart
>> reasons ("I need this on my machine") -- AND CHANGED -std=gnu++11 TO
>> -std=c++11. This is getting important soonish.
>>
>> Next up: checking the OS X version. For 10.9 (darwin 13) and higher, I
>> error out if configure.cxx_stdlib is set to libstdc++. Likewise, I error
>> out on 10.8 (darwin 12) and lower if configure.cxx_stdlib is set to libc++.
> 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.

If someone on <= 10.8 set libc++ globally... tough luck. He'll get an
error when trying to install the port. 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.


>> This leaves us with libc++ on 10.9+ and libstdc++ on 10.8-. Compatible
>> with the system C++ runtime. Good.
>>
>> For 10.9+ with libc++, only blacklisting all GCC versions is necessary
>> to not pull in libstdc++ accidentally.
>>
>> ===
>> Caveat: make sure the port does not use -std=gnu++11 on 10.9+. It WILL
>> make clang link to libstdc++ (even if passing -stdlib=libc++!), because
>> gnu++11 is "c++11 with GNU extensions", which libc++ naturally does not
>> provide.
>> ===
>>
>> 10.8- is a little bit more complicated. We need to make sure a recent
>> libstdc++ is available. What Apple ships might not be recent enough,
>> especially on 10.7 and 10.6.
> But then you'll run into problems that are more or less equivalent (or
> worse) to mixing libc++ and libstdc++.

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

At least this is how I understood
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html ("Goals" section)

I may have misunderstood it. If I did, please (anyone) enlighten me.


>> Thus comes:
>>
>> depends_lib-append          {path:lib/libstdc\\+\\+.6.dylib:libgcc}
>>
>> 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.)


>> 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.
>>
>> 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. That procedure isn't exactly automatic, though. 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++?

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



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150414/1151f713/attachment-0001.sig>