<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 5 Dec 2020, at 5:20 pm, Eric Borisch <<a href="mailto:eborisch@macports.org" class="">eborisch@macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="">It's part of the LLVM project, and can be built at the same time (<span style="font-family:monospace" class="">-DLLVM_ENABLE_PROJECTS=openmp)</span>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.</div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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 <span style="font-family: monospace;" class="">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 </span><font face="monospace" class="">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.</font></div><div><font face="monospace" class=""><br class=""></font></div><div><font face="monospace" class="">Chris</font></div><div><span style="font-family: monospace;" class=""><br class=""></span></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><div class=""> - Eric</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 5, 2020 at 9:20 AM Chris Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk" class="">jonesc@hep.phy.cam.ac.uk</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto" class=""><div dir="ltr" class=""><br class=""></div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On 5 Dec 2020, at 3:09 pm, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank" class="">ken.cunningham.webuse@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">Good morning!</div><div class=""><br class=""></div>Chris - I suspected it just needed the flag as well. There were some cmake rearrangements recently in libomp.<div class=""><br class=""></div><div class="">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.</div></div></blockquote><div class=""><br class=""></div>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...<div class=""><br class=""></div><div class="">Chris<br class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">K</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Dec 5, 2020, at 6:55 AM, Eric Borisch <<a href="mailto:eborisch@macports.org" target="_blank" class="">eborisch@macports.org</a>> wrote:</div><br class=""><div class=""><div dir="auto" class="">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.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Thanks,</div><div dir="auto" class=""> - Eric</div><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 5, 2020 at 7:04 AM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank" class="">ken.cunningham.webuse@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto" class=""><div class=""></div><div class="">the std:atomic thing was added in 2018, so something else seems funny... clang-3.4 supports c++11 after all...</div><div class=""><br class=""></div><div class="">libomp probably should not be a dependency of clang at all</div><div class=""><br class=""></div><div class="">if it was separate from clang, it can be installed using the current toolchain rathervthan block it</div><div class=""><br class=""></div><div class="">K</div><div class=""><br class="">On Dec 5, 2020, at 04:56, Chris Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk" target="_blank" class="">jonesc@hep.phy.cam.ac.uk</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Hi,</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">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.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">Note, the port already installs a different version for some systems, those using libstdc++ </div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class=""><a href="https://github.com/macports/macports-ports/blob/master/lang/libomp/Portfile" target="_blank" class="">https://github.com/macports/macports-ports/blob/master/lang/libomp/Portfile</a></div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">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...</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">Chris</div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On 5 Dec 2020, at 5:57 am, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank" class="">ken.cunningham.webuse@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""></div></blockquote></div></blockquote></div><div dir="auto" class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><blockquote type="cite" class=""><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class="">Attempting to install supertux complains on libomp.
Logfile shows compiler complaints about atomic and variable templates.
</pre></blockquote><div class=""><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class="">I noticed that the recent update to libomp-11 failed on 10.8 and 10.9 (and 10.6 and less).</pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class=""><br class=""></pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class="">This is not a big surprise — more likely a miracle that libomp up to 10.0 built without trouble on every system.</pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class=""><br class=""></pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class="">I will see if I can fix it — maybe I can — but even if so, libomp 12, 13, or … will be unbuildable eventually.</pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class=""><br class=""></pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class="">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.</pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class=""><br class=""></pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class="">Anyway, that is for the future. until libomp is fixed, every clang is dead on 10.8 and 10.9</pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class=""><br class=""></pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class="">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 …).</pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class=""><br class=""></pre><pre style="white-space:pre-wrap;font-family:monospace;background-color:rgb(255,255,255)" class="">Ken</pre></div></div></blockquote></div></blockquote></div></blockquote></div></div>
</div></blockquote></div><br class=""></div></div></blockquote></div></div></div></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>