Re: [MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'
> On Oct 15, 2020, at 9:32 PM, Ken Cunningham > wrote: > > 2. an “openmp” PortGroup that all ports that want openmp could subscribe to, > that forces an openmp setup that works for various systems. > > Not overly hard, I think. or maybe the compiler.openmp settings have become robust enough to not need a portgroup, I’d have to see...
Re: [MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'
We’d need: 1. the ability to install and keep a toolchain on the buildbot in some fashion I’m very in favour of this, if possible, but I can see that it is not trivial to implement — I think all the OS versions < about 10.12 should use clang-9.0 to build everything, and save us all a lot of trouble making ancient clangs work with current software (or vice versa, I guess). 2. an “openmp” PortGroup that all ports that want openmp could subscribe to, that forces an openmp setup that works for various systems. Not overly hard, I think. BTW I’m all in favour, should this be agreeable to all, as you have seen from the several tickets I opened aboutit. I tried to encourage openmp support a couple of years ago, and ran into pushback due to these unresolved issues. Ken > On Oct 15, 2020, at 8:57 PM, Christopher Chavez wrote: > >> Comment (by kencu): > >> …Ryan has made it clear he does not want every build to be forced to a >> macports clang compiler as that causes the drives on the buildbots to die >> prematurely due to all the installing and uninstalling of macports- >> clang-9.0 (or whichever is the head of the line at that time). > > Is this really something with no chance of being addressed, and which port > maintainers and users will have to live with? Is it undesirable to swap-in > another MacPorts prefix with e.g. clang 9.0 permanently installed? Or, rather > than writing extracted ports to disk to install them, is it possible on > macOS/would it not be undesirable to mount a prebuilt port's compressed > archive and then overlay/union it at the prefix? > >> And this is indeed how we came to disable openmp in virtually all builds, >> until Apple clangs supported openmp (which we all thought might happen >> before now, but has not happened). > > My impression is that this will never happen. It seems Apple would rather you > use whatever other choices for parallelism on their platform, such as Grand > Central Dispatch and Metal Compute, which they have more influence/control > over, which are usable from Swift, and can take advantage of SIMD on newer > CPUs/GPGPUs. POSIX threads might be one of the only cross-platform options > natively supported. > >> I would suggest we go back to disabling openmp for 99.99% of cases, unless >> people can sort this out for a specific lonely build, in a specific case, >> that can affect no other software. > > Pardon my naïvety on this whole subject, but I think it really would be nice > if MacPorts could offer the more performant choice without requiring users to > opt-in to variants (if they know what those are) or build locally. OpenMP > seems like a good way to support the increasing number of CPU cores in > systems without relying on non-backward-compatible SIMD CPU instructions > (unless those are what the SIMD support in recent OpenMP versions tries to > use). I think leaf ports such as for command-line utilities would be a good > place to start enabling OpenMP. > > Christopher A. Chavez
Re: [MacPorts] #61327: py-rpy2 build fails with clang: error: unsupported option '-fopenmp'
> Comment (by kencu): > …Ryan has made it clear he does not want every build to be forced to a > macports clang compiler as that causes the drives on the buildbots to die > prematurely due to all the installing and uninstalling of macports- > clang-9.0 (or whichever is the head of the line at that time). Is this really something with no chance of being addressed, and which port maintainers and users will have to live with? Is it undesirable to swap-in another MacPorts prefix with e.g. clang 9.0 permanently installed? Or, rather than writing extracted ports to disk to install them, is it possible on macOS/would it not be undesirable to mount a prebuilt port's compressed archive and then overlay/union it at the prefix? > And this is indeed how we came to disable openmp in virtually all builds, > until Apple clangs supported openmp (which we all thought might happen > before now, but has not happened). My impression is that this will never happen. It seems Apple would rather you use whatever other choices for parallelism on their platform, such as Grand Central Dispatch and Metal Compute, which they have more influence/control over, which are usable from Swift, and can take advantage of SIMD on newer CPUs/GPGPUs. POSIX threads might be one of the only cross-platform options natively supported. > I would suggest we go back to disabling openmp for 99.99% of cases, unless > people can sort this out for a specific lonely build, in a specific case, > that can affect no other software. Pardon my naïvety on this whole subject, but I think it really would be nice if MacPorts could offer the more performant choice without requiring users to opt-in to variants (if they know what those are) or build locally. OpenMP seems like a good way to support the increasing number of CPU cores in systems without relying on non-backward-compatible SIMD CPU instructions (unless those are what the SIMD support in recent OpenMP versions tries to use). I think leaf ports such as for command-line utilities would be a good place to start enabling OpenMP. Christopher A. Chavez
Re: Xcode 12 on Catalina?
> I've been putting off the upgrade to XCode 12 for a while, since I kinda > got burned by the upgrade from 10 to 11. I haven't seen any reports of > problems with the new version, but I thought I'd ask -- any reason not to > upgrade at this point? It seems the most frequently encountered issue so far is how implicit function declarations are now considered errors rather than warnings; reportedly this is done because of ABI requirements of macOS on ARM 64-bit. There have been tickets steadily reported every few days for affected ports. Sometimes these are due to forgetting to include a header file and is easy to fix (sometimes upstream has already began fixing them). Other times it is "old-school" C programming habits of intentionally declaring functions implicitly, and is more tedious/difficult to fix particularly without upstream developer involvement. Christopher A. Chavez
How to close a Trac ticket assigned to me
I checked https://trac.macports.org/wiki/TracTickets for details, but it looks like I cannot change status and resolution for a Trac ticket which is currently assigned to me. Is this deliberate? The "modify ticket" section of the web UI only offers me the option to reassign the ticket to somebody else. -Ralph
