Using -std=c++11 with the macports gcc-4.7 compiler

[Jeremy Huddleston Sequoia]

On Jan 16, 2013, at 19:44, Sean Farley <sean at macports.org> wrote:
>>> I personally have had clang++ bugs with libmesh, moose, armadillo, and
>>> dolfin.
>> 
>> There are plenty of g++ bugs as well ;) … have you filed radars (or at least llvm bugzilla reports) about all of the clang issues you are finding?  Can you point me to them?
> 
> Unfortunately, 1) I didn't report them at the time (and can't
> reproduce) and 2) some of the repos are private :-(

With newer versions of clang, it will output the preprocessed source and a shell script to run to reproduce the issue with the preprocessed source.  If it's not private, simply providing those two files (source and script) are a big help to the developers.  If it is private, you can hopefully come up with a reduced test case within 10 minutes or so and submit that.  Also, you may feel more comfortable submitting pseudo-private test cases to bugreport.apple.com rather than the llvm bugzilla as it will then be between you and Apple.

>>> What makes this sentiment frustrating is the whole "use this
>>> one version of the library with no optimization or debug control"
>>> which is at odds with "try this library with {gcc,clang,etc.}'s
>>> -O{1,2,3} and then write a paper about the results."
>> 
>> I'm not really sure I know what you're referring to with the above sentence.
> 
> Ah, I meant to explain the need for having multiple versions of a
> library / program with different optimization levels for numerical
> computation.

Ok, so you're analyzing the effects of different optimizations or something … yeah… in that case, you can't really work around it by using a different compiler or optimization set because you want to test *THAT* set.  That is certainly understandable.  You're bound to run into bugs with any compiler at -O3 and above.  Back when I was a Gentoo dev, I learned never to trust -O3 and above, and that rule has served me well.  Sometimes it's a corner case of a compiler bug, sometimes it's buggy source that "just works" without some strict optimizations… in general, if it's not widely tested, it's more likely to not work the way you want.  I don't really have a good answer to give you to this problem, but a good first step is to always report the bug.  Chance are you're one of a few people to ever trip over it based on your non-standard use case.

>>> This actually was
>>> my whole motivation for writing scienceports: provide a way to use a
>>> library with gcc4X or clang3X and somehow manage the combinatorial
>>> explosion of variants (the correct data structure, by the way, is a
>>> DAG).
>> 
>> How are you planning to manage the inherent difficulty with some clients using libstdc++ and libc++?  It's possible for two separate libraries to use different C++ runtime versions so long as they're not passing objects back and forth, but most of the time, libraries that are implemented in C++ provide C++ APIs to that library.
> 
> You are right to point out that a DAG alone won't solve compatibility
> issues. I just meant that it's impossible to do correct dependency
> analysis without having (or having something isomorphic to) a DAG.

Yeah, it would be great if dependencies were a nice tree, but they're not. =)

Seriously though, if you're using C++ extensively in your ports, you should try intermixing some builds with clang++ using libc++ and see what happens.  New symbol mangling will make interoperability difficult.  We may need to figure out a way to deal with this ABI compatibility issue in base … is there currently a way to query what configure.compiler was for another installed port?

>> Can you please provide the information I requested regarding libstdc++ linkage?
> 
> I thought you were talking to the guy that reported the error?

Yeah, it's late.  Forgive me =)

>> What other issues are you specifically frustrated with?
> 
> Pretty much just the ability to easily manage ports compiled with
> different compilers.

I don't think that will change any time soon.  It should hopefully be better now that we have just three C++ runtimes to worry about (host libstdc++, MacPorts libstdc++, and host libc++) instead of one for each gcc version … but things will get difficult if users start mixing libc++ and libstdc++.  You may see that I made a pass recently tackling some libc++ issues, and you can test your ports by adding -std=c++11 -lib=libstdc++ in configure.cxxflags.

--Jeremy