should be fixed with https://github.com/macports/macports-ports/commit/d88607f06cd18787529edcd9f7fb6dd5c26114bd <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 <[email protected]> wrote: > > 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 > > https://build.macports.org/builders/ports-10.8_x86_64-builder/builds/31506/steps/install-port/logs/stdio > > <https://build.macports.org/builders/ports-10.8_x86_64-builder/builds/31506/steps/install-port/logs/stdio> > > I don’t see -std=c++11 in the list of compiler options, so as c++11 is not > default for this old OS, it might just be a case of adding this > > configure.cxxflags-append -std=c++11 > > Chris > >> On 5 Dec 2020, at 1:03 pm, Ken Cunningham <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >>> <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 <[email protected] >>>> <mailto:[email protected]>> 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 >
smime.p7s
Description: S/MIME cryptographic signature
