It's part of the LLVM project, and can be built at the same time ( -DLLVM_ENABLE_PROJECTS=openmp)as other tools; I think losing OpenMP support for MP's clang by default is a step backwards, but most of the google results for "clang openmp mac" point you to homebrew anyway, so perhaps it doesn't matter.
- Eric On Sat, Dec 5, 2020 at 9:20 AM Chris Jones <[email protected]> wrote: > > > On 5 Dec 2020, at 3:09 pm, Ken Cunningham <[email protected]> > wrote: > > > Good morning! > > Chris - I suspected it just needed the flag as well. There were some > cmake rearrangements recently in libomp. > > Eric - it would not be a big deal to have libomp something needs to be > specified by the libomp PortGroup we either have or will need to make > libomp work right. By having it as a build/lilb/run dep for clang, that > means libomp has to be built with the oldest, frailest, least capable, > least optimizing compiler macports has available, rather than the current > compiler. > > > I agree with Ken here. If this does not really need to be a dep of clang > itself, but could be handled by the PG that handles MPI support, then we > should probably do this as minimising the deps that the clang ports have > makes things a lot simpler... > > Chris > > > K > > > > On Dec 5, 2020, at 6:55 AM, Eric Borisch <[email protected]> wrote: > > I’m fine moving either way (leave as a separate port, pinned to older > versions on older systems, or build it as part of each clang > independently), but I think removing it as something that comes along with > MP’s clang would be a mistake. > > Thanks, > - Eric > > On Sat, Dec 5, 2020 at 7:04 AM Ken Cunningham < > [email protected]> wrote: > >> the std:atomic thing was added in 2018, so something else seems funny... >> clang-3.4 supports c++11 after all... >> >> libomp probably should not be a dependency of clang at all >> >> if it was separate from clang, it can be installed using the current >> toolchain rathervthan block it >> >> K >> >> On Dec 5, 2020, at 04:56, Chris Jones <[email protected]> wrote: >> >> Hi, >> >> The problem is simply the latest version uses std::atomic, which requires >> c++11, and the usual fix of requesting this c++ standard in the port file >> does not work due to the fact this port is a clang dependency, so using >> clang as a fallback compiler is not possible. >> >> Note, the port already installs a different version for some systems, >> those using libstdc++ >> >> >> https://github.com/macports/macports-ports/blob/master/lang/libomp/Portfile >> >> So a relatively trivial fix would be to peg macOS 10.9 and older to the >> last version that builds there, version 10.x. Probably a bit simpler than >> having to deal with multiple libomp-X ports... >> >> Chris >> >> On 5 Dec 2020, at 5:57 am, Ken Cunningham < >> [email protected]> wrote: >> >> >> >> Attempting to install supertux complains on libomp. >> >> Logfile shows compiler complaints about atomic and variable templates. >> >> >> I noticed that the recent update to libomp-11 failed on 10.8 and 10.9 (and >> 10.6 and less). >> >> >> This is not a big surprise — more likely a miracle that libomp up to 10.0 >> built without trouble on every system. >> >> >> I will see if I can fix it — maybe I can — but even if so, libomp 12, 13, or >> … will be unbuildable eventually. >> >> >> So we’ll need to come up with a libomp plan. There is really no reason (I >> think) that we can only have one libomp — we could install the one that >> comes with each llvm and then it would always work, I think. Eg clang-9 >> would use libomp-9. >> >> >> Anyway, that is for the future. until libomp is fixed, every clang is dead >> on 10.8 and 10.9 >> >> >> BUT — good news. clang (and most everything else) doesn’t really need libomp >> anyway. I don’t even know why it is listed as a dependency, to be honest. >> Just delete from the clang portfile, and you’re good to go again, I think >> (haven’t tried it… but …). >> >> >> Ken >> >> >
