Native support for Apple Silicon (ARM64 architecture)

[frozenpandaman]

Feature description

A build of QGIS that runs natively on M1 Macs would be great to see.

https://doesitarm.com/app/qgis/

Additional context

No response

[BryanWall]

Feel free to share the binary! I can't install macports on my machine (heavily use Homebrew) but would love to get a faster copy of Qgis running over here.

Are you sure there's an issue with having both Homebrew and Macports on the same machine? I don't think there is, at least on Apple silicon (M1/M2) machines. Homebrew changed their install path for Apple silicon machines and it doesn't conflict with Macports. It shouldn't cause problems as long as you don't install the same packages using both (and then it still may not cause problems since one will have higher priority in your path).

I have a couple dozen packages installed with Homebrew, and several with Macports such as QGIS, and have not seen any conflicts or problems.

[georgeboot]

Are you sure there's an issue with having both Homebrew and Macports on the same machine?

You are right, Homebrew is now on a different path. Installed Macports and it indeed works without issues.

Installing qgis3 though, that's another beast. It wants to install all sorts of dependencies that could conflict with my prod setup. So no-go

So I spun on a MacOS Ventura virtual machine and I am compiling it on there. Will share once done.

[BryanWall]

Are you sure there's an issue with having both Homebrew and Macports on the same machine?

You are right, Homebrew is now on a different path. Installed Macports and it indeed works without issues.

Installing qgis3 though, that's another beast. It wants to install all sorts of dependencies that could conflict with my prod setup. So no-go

So I spun on a MacOS Ventura virtual machine and I am compiling it on there. Will share once done.

All of those Macports dependencies should also go into the same isolated path. Other things on your machine will have no reason to look there or even know it exists. Just make sure the Macports folder is below other things in the path. Maybe test it in the VM and confirm there are no issues before installing locally.

Building QGIS the first time took a while on my M1 Pro machine, but it has worked flawlessly through several versions. I have had an error pop up occasionally, but it has been related to plugins that need updating (even though the error doesn't suggest that).

[georgeboot]

Yeah testing in a VM at the moment. Getting many build issues though. Had to install beta command line tools to fix the first one, but currently stuck on some qt-qtbase issue I can't figure out. I'm on Ventura stable.

[BryanWall]

Yeah testing in a VM at the moment. Getting many build issues though. Had to install beta command line tools to fix the first one, but currently stuck on some qt-qtbase issue I can't figure out. I'm on Ventura stable.

Macports and has often had issues after new Macos versions are released that take a little while to be ironed out. Xcode 14.1, which is the version that's supposed to accompany Macos Ventura, has still not been released, so anything needing to use the Xcode CLI on Ventura is likely going to have issues.

Here's a thread with some discussion about Macports and Homebrew not working or probably needing the final Xcode 14.1 to work. Someone got it to work by manually installing the RC2 version.

https://forums.macrumors.com/threads/weird-that-they-didnt-release-xcode-14-1-yesterday-its-required-for-mac-os-13-development.2367293/

[Veence]

It is a very bad idea to try and compile QGis with the latest version of MacOS. Not because MacOS is unstable or w/e, but because Qt5, on which QGis is based, is hopelessly outdated. It’s already a miracle it works on MacOS(n-1), but don’t expect miracles to recur. The development team must really consent to a big effort and hitch up QGis on to Qt6, otherwise the software is doomed in the short term.

[swaxolez]

I tried with Ventura/Macports to no avail. I installed Xcode 14.1 RC2 which works fine. It gets hung up with PDAL:

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_pdal/PDAL/work/PDAL-2.4.2-src/vendor/gtest/include/gtest/gtest-printers.h:115:10: fatal error: 'absl/strings/string_view.h' file not found

[Veence]

As usual with each new MacOS version, some .h files disappear or are merged into other ones. It’s gonna take a while to unravel the knot… :/

[DreGilley]

Had the same issues with Ventura. Spun up a Monterey VM in Parallels and it built first try. Exported it as an mpkg and successfully installed / running it on my M1 Max MBP with Ventura 13.1 beta. Only hiccup is a nondescript Python error on launch, but QGIS continues to launch and seems to work fine.

[swaxolez]

As usual with each new MacOS version, some .h files disappear or are merged into other ones. It’s gonna take a while to unravel the knot… :/

I started unravelling and then thought better of it. Thank you for your work. I'll try what DreGilley suggested and build through a MacOS13 VM for now.

[MaintenanceCosts]

I've been trying to build via MacPorts on my M1 Max MBP running Ventura and have run into a whole succession of issues. I've worked around most of them one by one, but I'm still having trouble getting the qt5-qtwebkit package to build. So no successful build of QGIS on Ventura yet for me. In the meantime I've been using the Intel version under Rosetta.

To even get started with the build you'll need to install Xcode 14.1 RC2 and its command line tools and then do a fresh install of MacPorts after installing them.

[MaintenanceCosts]

Update: I successfully built an arm64 version of QGIS 3.28 through MacPorts on Ventura. It appears to work great.

These were the problems I had to resolve and their resolutions:

1. Almost nothing in Ventura MacPorts works with Xcode 14.0.1. Solution: install Xcode 14.1 RC2 and the 14.1 RC2 command line tools, and then reinstall MacPorts. (Apple released official 14.1 today, so now just upgrade Xcode via the App Store and the command line tools via Software Update before starting.)
2. gcc12 and libgcc12 would not build with libunwind-headers present. Solution: build gcc12 and libgcc12 separately before trying to build qgis3.
3. qt5-qtbase failed to configure because it was determined to turn a blind eye to the present-and-accounted-for Ventura SDK. Solution: add configure.sdk_version 13.0 to the portfile.
4. botan failed to build because it required a patch with fuzz, and apparently Ventura's built-in patch cannot deal with fuzz. Solution: submit a ticket, which was very promptly addressed by the maintainers.
5. qt5-qtwebkit failed to build because of some issue with header files that is beyond my level of understanding. Solution: find this ticket: https://trac.macports.org/ticket/63877 and add the lines suggested by i0ntempest in comment 18 to the portfile.
6. qwt-qt5 failed to build for the same reason as qt5-qtbase, with the same solution.
7. qgis3 itself failed to build because of a bug in the Python 3.10 framework installed by MacPorts. Solution: patch a file inside that framework to fix the bug. On my system the offending file was /opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/sipbuild/generator/outputs/pyi.py, and the typo was "sinature" instead of "signature" in line 497.

Did I spend way more time banging my head against this than I would have spent waiting for operations to complete under Rosetta 2? No question about it.

[Veence]

This is awesome! Thanks a lot for all your effort. I’m sorry you had to jump through so many hoops…

[felix-ht]

It is a very bad idea to try and compile QGis with the latest version of MacOS. Not because MacOS is unstable or w/e, but because Qt5, on which QGis is based, is hopelessly outdated. It’s already a miracle it works on MacOS(n-1), but don’t expect miracles to recur. The development team must really consent to a big effort and hitch up QGis on to Qt6, otherwise the software is doomed in the short term.

@MaintenanceCosts qgis 3.28 and up should support builds for qt6 so this might help with making builds on mac easier as one can use qt6 instead of qt5?

[MaintenanceCosts]

@felix-ht I don't have anything close to the skills to put together a qt6-based build of QGIS. But I hope someone with the appropriate knowledge does so, because I think qt5 is a foundation of sand at this point.

[Veence]

I’ll take a crack at it this weekend.

[MaintenanceCosts]

Thanks @Veence! Really appreciate all the work you've done to bring QGIS to M1.

[eatyourbaby]

I (stupidly) went on a painstaking journey of building QGIS with homebrew. Ports didn't work for me for which I assume is incompatibility with brew, but I can't part ways with brew.

I've been using it for a few days and everything works so far. I've tried to package it, but neither cmake nor macdeployqt can properly package it, and there's another level of dependency hell when it comes to library install names. I'll give packaging another try if people are interested, or make a brew formula (or maybe just a bash script – I've spent too much time on this already) if I can't get it to work.

[felix-ht]

@DingoBits A brew formula would be fantastic!

[MaintenanceCosts]

The situation for people building arm64 QGIS with MacPorts got a lot better with some updates to various MacPorts ports over the weekend. At this point I think the only issue left from the seven I listed above is the qt5-qtwebkit build failure.

[eatyourbaby]

I've started to slowly porting my build to homebrew. It'll take a while for sure though.

@MaintenanceCosts @Veence I'm not familiar with ports, but I checked out qt513-qtwebkit and it seems to be using an older version? The two-year-old HEAD works a lot better than its latest release for me. Here's my brew formula for qtwebkit. I haven't had the chance to test it on Ventura though.

[eatyourbaby]

So... After way too much kicking and screaming, I finally managed to package a build. For debug reasons, some features aren't packaged. There are also some features I haven't figured out how to package yet, like GrassGIS. This is highly experimental so expect breakages. For example, Python will blurt out an error at startup. I've given it a quick spin on Monterrey and everything seems fine so far. Let me know if you have any issues (and/or solutions).

In principle, you shouldn't trust random binaries from strangers, but there's a long way from here to a fully functional build script. I'll get some documentation together later. It'll take a while to decipher my notes into something coherent. I'm gonna take a break from this for now.

https://github.com/DingoBits/qgis-arm64-apple/releases

[RemiDesgrange]

@DingoBits I read your README and can't figure out how you end-up packaging the app? The compile part ok, but the packaging part? 🤔

Thx anyway !!!

[eatyourbaby]

@RemiDesgrange I'm still working on the documentation and I'm filling in the most important part first. Give me a week or so to complete it.

If you build QGIS with -DQGIS_MACAPP_BUNDLE=1, make install should automatically package a complete build in CMAKE_INSTALL_PREFIX, but it doesn't work properly. Most libraries won't be packaged, and many packaged library will still have their paths pointed to homebrew. The result is two copies of the same library gets loaded into memory and causes segfault.

I statically linked as much as possible in my last build to avoid whac-a-mole with too many dylibs. I used macdeployqt to continue packaging a more complete build, and then manually add the still missing libraries, e.g. Python. Then I had to correct all the install path with install_name_tool.

[kevjamco]

Very cool! I've successfully opened and loaded some layers in MacOS 13.0.1. This is exciting stuff.

[dawgermany]

Hi, i dont know if this is new information or relevant but on the topic of qt6 i read info that i didnt encounter in this thread (not a developer just curios reader)

---

Everything is in the master branch (and the vast majority was in the 3.28 release), so building either of those should give >good results on qt6

Originally posted by @nyalldawson in https://github.com/qgis/QGIS-Enhancement-Proposals/issues/243#issuecomment-1296348185

---

[Qgis-psc] QGIS grant report: Support building QGIS app on Qt 6 Nyall Dawson nyall.dawson at gmail.com Wed Aug 24 19:13:54 PDT 2022

Hi PSC,

I'd like to report the successful completion of this grant project. (see https://github.com/qgis/QGIS-Enhancement-Proposals/issues/243 for proposal details).

In a fortunate turn of events, I didn't encounter any of the previously expected significant issues during this work and as a result was able to proceed much further with the Qt 6 port then originally proposed!

The proposal originally concerned only porting the "gui" and "app" libraries to Qt 6, but I was able to complete also the "3d" and "server" libraries too. We now are at a stage where the majority of QGIS builds and runs without any significant issues on Qt 6. The github CI setup has been updated to also run the c++ tests for gui, app, server and 3d, and the majority of these have been fixed so that they pass on the Qt 6 builds too.

In addition, some tests which were failing under Qt 6 revealed some real QGIS bugs which have been fixed in the process of this work. (So there's a direct benefit for the existing Qt 5 builds too!).

As previously reported, the next major step toward Qt 6 is enabling python support for Qt 6 builds, and then running the full test suite (with all the 1000s of python based tests) so that we can get a more complete picture of exactly how stable and bug-free the Qt 6 port is.

Thanks again for the opportunity to undertake this work!

Nyall

https://lists.osgeo.org/pipermail/qgis-psc/2022-August/009864.html

---

Love the community effort, the qgis community always sparks some joy with me :)

[eatyourbaby]

I finally got around to write up the documentation. I also uploaded a build for the new 3.28.1, and applied a workaround for the Python error on startup.

I'm having less time on my hands these days. My plan is to keep up with new releases and spend some time to troubleshoot along the way. GRASS is still missing as I had trouble having it work reliably across systems, but I've got an idea and might be able to add it in the next release. I couldn't get QGIS to detect SAGA this time around (might be related to #51041?). I'm not a Geospatial [INSERT JOB TITLE HERE] and I don't need these features, so they're not a priority for me. It also means some other features might be broken because I don't use/couldn't properly test it. File an issue in my repo to let me know if you run into one.

@dawgermany The official advice was not to bother with QGIS when I started my first attempt, but I'll give it a try next time. That being said, there's a number of compatibility issues with QGIS and dependencies beyond Qt, like the Python error mentioned in the beginning and in this thread.

I'll stop updating about my build so that I don't pollute this thread. Here's my repo: https://github.com/DingoBits/qgis-arm64-apple. There's also a Homebrew now to make it easier to install and update: brew install --cask dingobits/dingobits/qgis-arm64 I see I rely on Homebrew a lot more than the official packagers, but if there's anything I can help with an official build, I'm happy to assist.

[BryanWall]

After this update https://github.com/macports/macports-ports/pull/16890, QGIS3 builds and runs OK under Macos Ventura on M1 machines with Macports.

It takes a long time to build and on the first attempt Macports prompted me to deactivate "libunwind-headers" because it was conflicting with one of the build steps. After I did that the build finished. I'm not sure what else needs libunwind but it seems like it can be re-enabled after building Macports.

[Veence]

It takes a long time to build and on the first attempt Macports prompted me to deactivate "libunwind-headers" because it was conflicting with one of the build steps. After I did that the build finished. I'm not sure what else needs libunwind but it seems like it can be re-enabled after building Macports.

Unfortunately, and I don’t know why, having myself being dragged away from Macports during the last months, no port binaries seem to be available for the ARM-64/M1 arch. Which means all ports are compiled from source, and that indeed takes a long time.

Well, no pain, no gain :)

That being said, the libunwind-headers and sometimes other ports deactivation is (usually) caused by a conflict of header files. The port being compiled has a foo.h file it wants to include, but foo.h already exists in /opt/local/include and gets pulled instead, which results in compilation errors. Deactivation moves the /opt/local/include/foo.h file temporarily out of the way.

[Jerry23011]

Hi guys, I noticed that this issue has been around for more than a year. I'm just wondering if there is any chance for qgis development team to compile a native arm64 version anytime soon? Do we have to wait for the porting to Qt 6? I'm not a professional developer, so I'm looking for an official release, lol

[momeni133]

Still waiting for the native version on my M1 macbook

[MtnBiker]

I hope this effort continues. The current brew version is very slow for some cases. I have a lot invested in staying with HomeBrew so am reluctant to jump over to MacPorts. A short trial of DingoBit's version brew install --cask dingobits/dingobits/qgis-arm64 has been good, but he says he's unable to continue to develop it. UPDATE: Crashes and can be slow too.

[georgeboot]

Try the conda version, it works like a charm

[justinbb]

Indeed, at the moment the only way to get up-to-date QGIS on Mac is through conda, for either Apple Silicon or Intel.

The MacPorts version has unresolved issues with GDAL and has not been updated in the past few weeks. The standard Homebrew formula for QGIS simply provides the official Mac build from qgis.org. (And yes, the DingoBIts version was a great proof of concept but not continued; it was clearly a demanding task.)

The official Mac build process has been unmaintained for close to 2 years – yet its dependency system requires intense manual maintenance (what were they thinking???). No attempt has been made to compile for Apple Silicon. Even the work on the primary goal – to provide a drag-and-drop install of a conformant Mac app bundle – was never completed (the bundle cannot be notarized even though it's signed by an Apple Developer ID, because its structure is wrong).

[dlejay]

I would not recommend the conda version. It is outdated and crashes.

[joaoponceleao]

@dlejay The conda version is not outdated. It's being kept up to date, both with QGIS and the underlying libraries. As for stability, I'm afraid I also can't recommend it - there are issues with several functions / algorithms not working (probably all sharing the same dependency). I also see no benefit between the conda arm version and the official intel version at this time. I imagine we will have to wait for QT6 and a proper port to Mac. I see no reason why this can't take place in conda however - it may make things easier.

[dawgermany]

I would not recommend the conda version. It is outdated and crashes.

+1 not Outdated but did not install for me the way it is supposed; also crashes a lot

[pathmapper]

There's a QEP "Conda Installer for macOS" -> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/270

[joaoponceleao]

Thanks @pathmapper I added a small comment to that QEP. I'm not crazy about a conda installer, but if it means that the same system can be used for Linux, Mac and windows, that should help maintenance a lot.

[eflaten]

Is there anyone who can provide remote access to a M1 mac may be it's better to donate a M1 😊

You can rent macos on Mac mini with M1 at Amazon Web services.

[nilason]

A number of GIS related ports have recently been updated and are available with MacPorts, also on native ARM arch! QGIS 3, Qt 5 has now no issues, GDAL 3.7, GRASS 8, latest PDAL… works great! ECW is unfortunately still only available with x86x_64 (due to limited Hexagon SDK support).

[nilason]

FYI, GIMP has a MacPorts based build, scripts located at https://gitlab.gnome.org/Infrastructure/gimp-macos-build.

[tsmcgrath]

@eflaten I would potentially support this for you if you could provide what you plan to do and what the cost would be on the Amazon Web services for an M1. If that will work. My system is wide open yet my QGIS processes are pegged. I don't have an infinite supply to support this but I would be able to provide some to help the community, and myself, with this issue.

[justinbb]

@tsmcgrath There is not currently any problem with compiling QGIS for Apple Silicon. If you are content with environments for using open-source software on Mac, you can get a completely up-to-date Apple Silicon build of QGIS by using conda (QGIS and libraries are in the conda-forge repository); see also article. QGIS is also present on MacPorts.

The difficulty is producing a properly packaged, codesigned, notarized application bundle of QGIS; the previous half-way solution was abandoned before the Apple Silicon transition. As mentioned above, the problem is now in hand (see QEP 270). For more background, see qgis/QGIS-Mac-Packager#160.

[selimnairb]

What's the barrier to packaging a signed, notarized bundle? Are these build instructions the most "up-to-date" description of the general process? (realizing that they are at least somewhat out of date: e.g. GRASS version, GEOS version). I would be willing to put some effort into moving this forward if there is a relatively clear starting point.

[tsmcgrath]

@justinbb thanks mucho for the clarification.

[RemiDesgrange]

What's the barrier to packaging a signed, notarized bundle? Are these build instructions the most "up-to-date" description of the general process? (realizing that they are at least somewhat out of date: e.g. GRASS version, GEOS version). I would be willing to put some effort into moving this forward if there is a relatively clear starting point.

Shell scripts from https://github.com/qgis/QGIS-Mac-Packager are outdated. Upgrading it and packaging it (yes, you package the deps as a zip, to then package QGIS as a DMG) is very time consuming. Last time I tried some deps couldn't be compiled for Apple Silicon Arch. Then you'll need to parametrize all homebrew path that are using /usr/local to be able to compile for both x86_64 and AppleSilicon arch (that's the easy part).

But I have no idea if the people behind https://github.com/qgis/QGIS-Mac-Packager wants to maintain it or not.

[tsmcgrath]

This is moving forward with this issue: https://github.com/qgis/QGIS-Enhancement-Proposals/issues/270

[justinbb]

@RemiDesgrange The existing QGIS-Mac-Packager's dependency management was maintained by the people behind it until about three years ago when they bowed out. Its inspiration, OSGeo4A, has also abandoned this way of doing things, as it is fundamentally unmaintainable. As for the actual packaging, the job was never completed – the Mac bundle produced by the QGIS-Mac-Packager is not organized strictly enough to pass through Apple notarization.

Consequently, it is necessary to start over (possibly salvaging some parts of the old packager), and this is what QEP 270 is about. Since that proposal has been funded and is going ahead, we (Mac QGIS users) just have to be patient.

[MaintenanceCosts]

So, stubbornly wanting both AS-native code and an app bundle, I've been continuing to use the MacPorts version (which works great for the subset of QGIS features I use). Just tried to build QGIS 3.32.3 under Sonoma. There were a few issues building the dependencies but I worked my way through all of them. Now qgis3 itself won't build. Here are the log lines that seem to show the error happening:

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_qgis3/qgis3/work/QGIS-3_32_3/src/core/processing/qgsprocessingfeedback.cpp:129:5: error: invalid token at start of a preprocessor expression
:info:build #if PDAL_VERSION_MAJOR_INT > 1 || (PDAL_VERSION_MAJOR_INT == 1 && PDAL_VERSION_MINOR_INT >= 7)
:info:build     ^
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_qgis3/qgis3/work/build/qgsconfig.h:107:32: note: expanded from macro 'PDAL_VERSION_MAJOR_INT'
:info:build #define PDAL_VERSION_MAJOR_INT /bin/sh: line 1: 30947 Trace/BPT trap: 5       /opt/local/bin/pdal --version 2>&1
:info:build                                ^
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_qgis3/qgis3/work/QGIS-3_32_3/src/core/processing/qgsprocessingfeedback.cpp:132:72: error: no member named 'GetFullVersionString' in namespace 'pdal'; did you mean 'pdal::Config::fullVersionString'?
:info:build   pushDebugInfo( tr( "PDAL version: %1" ).arg( QString::fromStdString( pdal::GetFullVersionString() ) ) );
:info:build                                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~
:info:build                                                                        pdal::Config::fullVersionString
:info:build /opt/local/include/pdal/pdal_config.hpp:58:22: note: 'pdal::Config::fullVersionString' declared here
:info:build PDAL_DLL std::string fullVersionString();
:info:build                      ^

Any thoughts or help would be very welcome.