Problem with libomp (was supertux)

[Eric Borisch]

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 <jonesc at hep.phy.cam.ac.uk> wrote:

>
>
> On 5 Dec 2020, at 3:09 pm, Ken Cunningham <ken.cunningham.webuse at 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 <eborisch at 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.webuse at 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 <jonesc at 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
>>
>> 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.webuse at 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20201205/b69c65ce/attachment-0001.htm>