On Wed, Jan 16, 2013 at 10:06 PM, Jeremy Huddleston Sequoia <jerem...@macports.org> wrote: > > On Jan 16, 2013, at 19:44, Sean Farley <s...@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.
I did not know that. That's pretty awesome, actually. I'll have to keep it in mind. >>>> 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. Agreed. We've filed many bug reports with Intel's compilers over the years :-) In fact, Intel's -O3 _still_ crashes in some cases! >>>> 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. =) But! It is a graph! It's just sometimes a bad graph :-( > 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. I have put off doing this due to time. I have some pure C++ projects to incorporate in the next few weeks that might be good candidates. > 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? I ran into this issue as well but couldn't find an easy answer. I solved it by using custom variants, e.g. petsc +debug +gcc47, and then writing my own tool to activate / deactivate all dependent ports of a certain variant at once so that I could switch, say, everything petsc depended on to use +debug +gcc48. >>> 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 =) No worries :-) >>> 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. Hmmm, this definitely reaffirms my decision to stick with strict C for my dissertation :-) As for the other numerical packages I have in C++, I'll have to slowly test them over the next few weeks as I have time. I appreciate all the help in explaining these things and also appreciate your efforts at Apple. Thanks, Jeremy! _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users