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.
> 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.
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.
> No, libstdc++ is explicitly designed to allow multiple, incompatible
> libstdc++ version being in use at the same time.
Why do people report problems then?
>>> 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. 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.
>>>
>>> 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.
> That procedure isn't exactly automatic, though.
It is on 10.6.
> 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.
> 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.)
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@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
