Re: Problem with libomp (was supertux)

On Sat, Dec 5, 2020 at 1:25 PM Ken Cunningham < ken.cunningham.web...@gmail.com> wrote: > > > > On Dec 5, 2020, at 11:21 AM, Eric Borisch wrote: > > > > We could: > > > > * leave the current patch applied to clang-* (to teach clang where to > get the library if it is installed) > > * make

Re: Problem with libomp (was supertux)

> On Dec 5, 2020, at 11:21 AM, Eric Borisch wrote: > > We could: > > * leave the current patch applied to clang-* (to teach clang where to get > the library if it is installed) > * make clang-* no longer depend upon libomp > * Add a post-install note of "to enable OpenMP support, install

Re: Problem with libomp (was supertux)

We could: * leave the current patch applied to clang-* (to teach clang where to get the library if it is installed) * make clang-* no longer depend upon libomp * Add a post-install note of "to enable OpenMP support, install libomp" * Have libomp depends_build upon the latest clang on the

Re: Problem with libomp (was supertux)

> On Dec 5, 2020, at 10:18 AM, Christopher Jones > wrote: > > Hi, > >> On 5 Dec 2020, at 5:20 pm, Eric Borisch > > 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

Re: Problem with libomp (was supertux)

Hi, > On 5 Dec 2020, at 5:20 pm, Eric Borisch 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

Re: Problem with libomp (was supertux)

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

Re: Problem with libomp (was supertux)

> On 5 Dec 2020, at 3:09 pm, Ken Cunningham > 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

Re: Problem with libomp (was supertux)

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

Re: Problem with libomp (was supertux)

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

Re: Problem with libomp (was supertux)

should be fixed with https://github.com/macports/macports-ports/commit/d88607f06cd18787529edcd9f7fb6dd5c26114bd built for for me in my 10.9 VM. > On 5 Dec 2020, at 1:11 pm, Christopher Jones wrote:

Re: Problem with libomp (was supertux)

Hi, c++ standard support in compilers isn’t always black and white. Compilers often claim to support a given standard, but then fail in some corner cases.. That said, in this case looking at

Re: Problem with libomp (was supertux)

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

Re: Problem with libomp (was supertux)

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