Problem with libomp (was supertux)

[Chris Jones]

> 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/5a347ad2/attachment.htm>