Hi, > On 5 Dec 2020, at 5:20 pm, Eric Borisch <ebori...@macports.org> wrote: > > 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.
No one is suggestion removing support for it, just a different way of packaging. To be honest having openmp as a port external to the LLVM ports has never made complete sense to me. Currently the way the LLVM suite of ports are built is a bit peculiar and frankly a bit of a relic from SVN days and doesn’t use the LLVM_ENABLE_PROJECTS option to enable components. I believe Ken has looked into using this to simplify the builds, which I think would be good, and then enabling it would be a lot simpler than it currently is. Doing this for all the current LLVM versions is not really practical but perhaps for a future release (maybe an update to 11) we should move to this way of building thing, and then for that version remove the external libomp port dep. and just build it as part of the LLVM port itself. Chris > > - Eric > > On Sat, Dec 5, 2020 at 9:20 AM Chris Jones <jon...@hep.phy.cam.ac.uk > <mailto:jon...@hep.phy.cam.ac.uk>> wrote: > > >> On 5 Dec 2020, at 3:09 pm, Ken Cunningham <ken.cunningham.web...@gmail.com >> <mailto:ken.cunningham.web...@gmail.com>> 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 <ebori...@macports.org >>> <mailto:ebori...@macports.org>> 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 >>> <ken.cunningham.web...@gmail.com <mailto:ken.cunningham.web...@gmail.com>> >>> 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 <jon...@hep.phy.cam.ac.uk >>> <mailto:jon...@hep.phy.cam.ac.uk>> 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 >>>> >>>> <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 >>>>> <ken.cunningham.web...@gmail.com >>>>> <mailto:ken.cunningham.web...@gmail.com>> 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 >>
smime.p7s
Description: S/MIME cryptographic signature
