<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On 5 Dec 2020, at 3:09 pm, Ken Cunningham <ken.cunningham.webuse@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><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><br></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><br></div><div>Chris<br><div><br><div><blockquote type="cite"><div dir="ltr"><div class=""><br class=""></div><div class="">K</div><div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 5, 2020, at 6:55 AM, Eric Borisch <<a href="mailto:eborisch@macports.org" class="">eborisch@macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><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" 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></body></html>