On 08 August, 2025 - Robert Helling via subsurface wrote: > Hi, > > once more, I keep running into a brick wall building Subsurface on my > Macbook. It has always been difficult since I got one with Apple Silicon ARM > chip, but at some point it worked. Unfortunately, that was a while ago and > since there have been MacOS updates as well as homebrew updates. Also, more > recently I used another laptop running Linux for Subsurface activities as > there life is so much easier in this respect. But now I am going to depart on > my summer vacation and I only want to take the Mac with me (as it contains > all my actual work stuff) and don't carry two laptops. So I tried the usual > things: removed the build directory, removed all libdivecomputer related > files, started from a fresh ~/src directory and cloned subsurface from > github, even set up a new user account and started from there with > downloading everything. I still get stuck.
I generally don't do macos, but it shouldn't be that hard. There are nowadays github actions runner images for macos-15-arm64 so that could be a good place to experiment and ensure we have something that actually works, for some values of works. > > Here is what happens: > > If I run > > subsurface/scripts/build.sh -make-deps > > I get stuck in building libz, where it complains about incopatible versions > of automake (and friends) and no obvious way to resolve that. What provides automake and frends? Xcode? Homebrew? Both? > > If I run it without -make-deps (using the libraries and install-root from the > oldtimes when things worked) the build of libdivecomputer fails in the > linking stage where the linker complains about libusb and libhid (as provided > by homebrew) only having Intel architecture symbols but not the required arm > symbols. > > Anybody got any ideas what to do or even willing to resolve these issues in a > zoom session? >From memory, you're allowed to virtualize macos on apple hardware, so I'd start by setting up a clean environment there. It's faster turnaround times than waiting for github actions to build everything when experimenting and trying to fault find. Another solution would be to just run a virtualized linux machine to get your subsurface fix from it. //Anton > > Thanks a lot > Robert > > > -- > .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO > Robert C. Helling Elite Master Course Theoretical and Mathematical Physics > Scientific Coordinator > Ludwig Maximilians Universitaet Muenchen, Dept. Physik > Phone: +49 89 2180-4523 Theresienstr. 39, rm. B339 > http://www.atdotde.de > > Enhance your privacy, use cryptography! My PGP keys have fingerprints (new > since May 2020) > 85FD 9B32 4F0D E894 AD4F 8E45 78E3 F3BF 19DF 9623 and > 114D 0323 FCC9 B9D7 B293 46DE A86D 66BC C29B D6EF and > FD81 EF06 E1C7 8364 F364 9EBC 0DA3 6E77 529D F349 > > > > > _______________________________________________ > subsurface mailing list -- subsurface@subsurface-divelog.org > To unsubscribe send an email to subsurface-le...@subsurface-divelog.org _______________________________________________ subsurface mailing list -- subsurface@subsurface-divelog.org To unsubscribe send an email to subsurface-le...@subsurface-divelog.org
