Update documentation for compilation under macOS #5590

rfranke · 2019-12-31T08:02:13Z

First of all: thank you for the great software and comprehensive documentation!

The compilation of the current dev branch was straightforward under Linux Ubuntu 18.04. I just ran the documented sudo apt install ... and picked the build commands out of the supplied build-rawtherapee shell script.

The compilation under macOS Catalina 10.15.2 was more tricky. This might be due to my ignorance on that system, but possibly an updated documentation would help as well.

It wasn't clear to me that Homebrew and MacPorts are alternatives. Some packages are only listed for Homebrew, in particular cmake and libomp. This is why I installed both and then wasted some hours treating conflicts with duplicated installations of things like expat and gtk3. The documentation should make clear that one should decide for either Homebrew or MacPorts.

I finally deinstalled Homebrew and added missing packages to MacPorts. Then things turned out considerably simpler than documented:

MacPorts rejected to install clang-3.9. I tried clang-8.0 and clang-9.0 instead. Both failed with linking a simple program during cmake. I did nothing in the end, i.e. just used the system compiler coming with Xcode -- Apple clang version 11.0.0 (clang-1100.0.33.16). The use of a custom compiler might be documented in a separate advanced section to make things simpler to start with.
I had to manually add omp locations for cmake with MacPorts -- as documented for Homebrew. Interestingly I did not seem to need this for Homebrew. However, an omp test failed at the end of cmake -- will do speed comparisons with the released RawTherapee 3.7 and then follow up on this one eventually.
I skipped the libiconv patch. It would have applied to version 1.15, whereas MacPorts installed 1.16. Everything seems fine (not more sporadic crashes during startup than with the released RawTherapee 3.7).
Section "Distribution Bundle Framework Library Versions in 5.5-dev" appears outdated.
Last section "macOS 10.15": I did not copy the result to /Applications; just started it from the command line in the build directory instead. Then the Terminal cares about access rights to removable media. I do also need to start the released version 5.7 under /Applications/RawTherapee/Contents/MacOS/rawtherapee from the command line for access rights to memory cards.

The text was updated successfully, but these errors were encountered:

heckflosse · 2019-12-31T21:17:45Z

@rfranke

However, an omp test failed at the end of cmake -- will do speed comparisons with the released RawTherapee

Without omp RT will be slow. Imho not worth to make a non omp build for machines with multiple cores...

rfranke · 2019-12-31T22:44:10Z

I did some comparisons with the released version 5.7 today. Went back to branch release-5.7 as the processing seems to have changed in dev. Setting
-DWITH_LTO="ON"
results in the same speed even without omp (about 4s to open a photo in the editor :-( ). Maybe something went wrong with the release build -- or with Catalina? See also #5552. This is why I'm hoping for #1678 now.
Btw: did not get any other than Xcode compiler to work. Hombrew llvm and MacPorts clang both fail to link a simple program on my 10.15.2 system.

heckflosse · 2020-01-01T00:17:47Z

@rfranke

Setting
-DWITH_LTO="ON" results in the same speed even without omp (about 4s to open a photo in the editor :-( ).

Can you post the console output when RT started from terminal with this enabled and opening an e.g. 24 MP raw?

rfranke · 2020-01-01T10:14:40Z

OK, I had a deeper look now. The measured times reduce as expected with omp. The effect on the overall wall clock time isn't that big though. Interestingly my perception of the effect of LTO was wrong.

Here are the measures using an Intel Mobile Core i5 "Haswell" (I5-4258U) 2.4 GHz with 2 physical cores. The released 5.7 build gives:

CA correcting 5599x3728 image with 2 tiles per thread
CA correction took 728 ms
Demosaicing 5599x3728 image using AMaZE with 2 Tiles per Thread
amaze demosaic took 812 ms

This sums up to about 1.5s. The total wall clock time between clicking on a tile and seeing the readily rendered photo is 3-4s (towards 3) though. Meaning about 2s other processing.

My own build of branch release-5.7 with Apple clang version 11.0.0 (no omp support) and -DWITH_LTO="ON" gives:

CA correcting 5599x3728 image with 2 tiles per thread
CA correction took 1433 ms
Demosaicing 5599x3728 image using AMaZE with 2 Tiles per Thread
amaze demosaic took 1562 ms

The total wallclock time increases to 4-5s. This reflects the loss of omp, but the other processing time of about 2s remains the same, so that the total loss of performance is not that big.

Unfortunately LTO increases the time for linking rawtherapee considerably. This is why I'm turning it off for experimental builds. An own build with -DWITH_LTO="OFF" gives:

CA correcting 5599x3728 image with 2 tiles per thread
CA correction took 1471 ms
Demosaicing 5599x3728 image using AMaZE with 2 Tiles per Thread
amaze demosaic took 1607 ms

Only minimal increase of measured times. Also the total wall clock time only increases slightly -- more towards 5s now.

heckflosse · 2020-01-01T11:11:58Z

@rfranke What kind of raw files did you use for your test?

rfranke · 2020-01-01T12:39:38Z

I'm processing NEF files from a D500 (file size about 24 MB). Do you think that 3s for opening a file in the editor are as expected?
This timing is less important when preselecting photos in the file browser (I'm shooting RAW+JPEG and only need to edit few photos). 100% zoom would be nice though, see #5591.

Meanwhile my own build works with omp using MacPorts clang-mp-9.0. It achieves the same times as the released version, if not a tad faster. Found https://trac.macports.org/ticket/58333#comment:8

sudo port -v uninstall ld64
sudo port -v install ld64 +ld64_xcode

Moreover, MacPorts fftw-3-single does not seem to contain libfftw3f_omp. The cmake test and the build work with libfftw3f_threads though.

heckflosse · 2020-01-01T13:50:00Z

I'm processing NEF files from a D500 (file size about 24 MB). Do you think that 3s for opening a file in the editor are as expected?

Are you using SETM or METM? If you use METM opening a new editor also takes a while.
Time to open a file in editor also depends on the profile you use. If you use for example 'Auto-matched...' the file will be decoded twice.

rfranke · 2020-01-01T13:59:58Z

SETM for the reported times, i.e. clicked on thumbnails in the Filmstrip. The Auto-Matched Tone Curve was the killer feature that convinced me to start with RawTherapee :-)

learmj · 2020-01-01T18:40:20Z

@rfranke since you are building and running with Mac OS Catalina, with respect to #5552 how does the RT UI behave for you, eg when moving sliders, moving curves, etc?

rfranke · 2020-01-01T20:42:22Z

Generally fine. The released binaries for version 5.7 and my own build behave alike. If I try to move a slider very fast, then I notice a lag of some milliseconds while the editor updates the photo. Only scrolling with gestures on the track pad or with an Apple mouse is too sensitive -- must use the scrollbars instead.
My only real problem is that RT doesn't exploit the resolution of the monitors when viewing photos, see #5591.

learmj · 2020-01-01T21:47:08Z

Interesting. If you drag a curve (eg RGB), does the point on the curve follow the mouse closely and smoothly, or does it lag? Are you using a separate (non Apple) mouse when working with a MacBook or other Apple machine rather than the trackpad (or magic mouse)? From your description it sounds like the issue I've been observing could be purely due to the use of the trackpad (I've not used a discrete and non apple mouse). Goes off to try and find one...

…

On Wed, 1 Jan 2020, 20:42 rfranke, ***@***.***> wrote: Generally fine. The released binaries for version 5.7 and my own build behave alike. If I try to move a slider very fast, then I notice a lag of some milliseconds while the editor updates the photo. Only scrolling with gestures on the track pad or with an Apple mouse is too sensitive -- must use the scrollbars instead. My only real problem is that RT doesn't exploit the resolution of the monitors when viewing photos, see #5591 <#5591>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5590?email_source=notifications&email_token=ACM6NAKF2LYYKYTOGGJ2SIDQ3T527A5CNFSM4KBTPUZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH5MGJI#issuecomment-570082085>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACM6NAOWKC4GTHRMMV4KK2DQ3T527ANCNFSM4KBTPUZQ> .

rfranke · 2020-01-02T07:53:18Z

Yes, when dragging points on curves or sliders, they follow the mouse closely and smoothly. Just scrollbars sometimes seem to hang -- but this I'm used to from the GNOME desktop as well.
I used the built-in touchpad and an Apple Magic Mouse so far. Interestingly: scrolling works nicely too (like under Linux) with a regular PC mouse and scroll wheel. The Magic Mouse works better for other programs, like Web browsers. It seems to have a higher amplification of slow scroll actions.

Benitoite · 2020-01-04T17:04:23Z

So I noticed in dev the default package manager has been changed to Homebrew from MacPorts.
This PR retains that new default but also allows for /opt
#5598

rfranke · 2020-01-04T18:33:47Z

I had started open minded without previous knowledge of either Homebrew or MacPorts. After having tried both, the latter convinces me more (regular installer instead of copy/paste of hacky command line, use of sudo, unique names, less PATH juggling). Appreciating your pull request!

Benitoite · 2020-01-04T19:49:46Z

Thanks @rfranke for having a look. Same experience here. I’d used apt before on Linux and find macports to be as simple. Homebrew is a slightly different paradigm but is supported by some autobuilders. PS I updated the pr after discovering a typo that occurred.

Beep6581 · 2020-01-24T11:28:24Z

Hey, what is the status?

rfranke · 2020-01-25T06:40:59Z

The build process works nicely with MacPorts -- much simpler imho. Everything works, including also omp. RT runs from the build directory. Unfortunately make macosx_bundle generates a bundle with .dylib conficts. #5598 does not help either for me.

Beep6581 · 2020-01-25T15:55:03Z

Does our documentation in RawPedia reflect the most recent approach? i.e. can we close this issue?

Benitoite · 2020-01-25T16:13:19Z

I noticed the script uses 'cp' in places instead of 'ditto' causing version errors. PR will be forthcoming.

…

On Jan 24, 2020, at 10:41 PM, rfranke ***@***.***> wrote: The build process works nicely with MacPorts -- much simpler imho. Everything works, including also omp. RT runs from the build directory. Unfortunately make macosx_bundle generates a bundle with .dylib conficts. #5598 does not help either for me. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

rfranke · 2020-01-25T16:40:47Z

@Benitoite: sounds promising!
@Beep6581: the documentation should still be updated.

better separate the descriptions of Homebrew and MacPorts build from each other -- I think one should not mix both as I did first, but decide for one
sudo port install: update clang-3.9 to clang-9.0 and add libomp
libiconv patch does not appear needed anymore (maybe shift to an appendix)
outdated versions in section: Distribution Bundle Framework Library Versions in 5.5-dev
maybe add cmake argument -DCMAKE_CXX_FLAGS="-Wno-deprecated-register"

Benitoite · 2020-02-21T15:26:19Z

Did some updates of https://rawpedia.rawtherapee.com/MacOS

Added -Wno-pass-failed -Wno-deprecated-register (thanks to @heckflosse et al. the build is quiet except loop vecorizations that go away with no-pass-fail. The non vectorizing loops still show during the LTO, which is not bad because LTO takes a few minutes).
Outdated library version section removed outright.
Updated libiconv patch to 1.16. (note: I still build the lib with it but haven't gone back and looked into the original issue for a test):

cd ~/libiconv* && LIBRARY_PATH="/opt/local/lib" LD=ld CC=clang CXX=clang++ CFLAGS="-arch x86_64 -mmacosx-version-min=10.9 -I/opt/local/include" LDFLAGS="-arch x86_64 -mmacosx-version-min=10.9 -L/opt/local/lib" CXXFLAGS="-arch x86_64 -mmacosx-version-min=10.9" ./configure --prefix=/opt/local --disable-static && LIBRARY_PATH="/opt/local/lib" LD=ld CC=clang CXX=clang++ CFLAGS="-arch x86_64 -mmacosx-version-min=10.9 -I/opt/local/include" LDFLAGS="-arch x86_64 -mmacosx-version-min=10.9 -L/opt/local/lib" CXXFLAGS="-arch x86_64 -mmacosx-version-min=10.9" ./configure --prefix=/opt/local --disable-static 'CFLAGS=-arch x86_64 -mmacosx-version-min=10.9 ' 'LDFLAGS=-arch x86_64 -mmacosx-version-min=10.9 ' CXXFLAGS="-arch x86_64 -mmacosx-version-min=10.9" && curl https://raw.githubusercontent.com/Beep6581/RawTherapee/dev/tools/osx/libiconv_1.16_rt.patch -o libiconv_1.16_rt.patch && patch -p1 < libiconv_1.16_rt.patch && LIBRARY_PATH="/opt/local/lib" LD=ld CC=clang CXX=clang++ CFLAGS="-arch x86_64 -mmacosx-version-min=10.9 -I/opt/local/include" LDFLAGS="-arch x86_64 -mmacosx-version-min=10.9 -L/opt/local/lib" CXXFLAGS="-arch x86_64 -mmacosx-version-min=10.9" make -j8 && sudo make install && libtool --finish /opt/local/lib

Added warning box at beginning of MacPorts section.

rfranke · 2020-02-23T15:46:47Z

Just tested the updated documentation. Much better now!

Following things might be changed:

section MacPorts: add libomp to sudo port install
section MacPorts: sudo port install ld64 +ld64_xcode with two l
section libiconv patch: don't need this anymore
section Compile RawTherapee: clang-mp-9.0 and clang++-mp-9.0 to get the compiler installed with MacPorts, as opposed to /usr/bin/clang
section Compile RawTherapee: add -DLOCAL_PREFIX:PATH="/opt" \ to cmake arguments (needed by macosx_bundle.sh)
section Compile RawTherapee: can't -DWITH_LTO="OFF" \ be deleted?

RawTherapee compiles and runs from the build directory.
If I add LOCAL_PREFIX (see above) and place the resulting RawTherapee.app in /Applications, then it almost runs as well. Unfortunately still get:

(rawtherapee-bin:31346): Gtk-WARNING **: 16:26:36.528: Could not load a pixbuf from /org/gtk/libgtk/theme/Adwaita/assets/check-symbolic.svg.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /Applications/RawTherapee.app/Contents/Resources/share/icons/Adwaita/16x16/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Abort trap: 6

The file image-missing.png is there though:

Benitoite · 2020-02-23T16:37:13Z

Great, @rfranke thanks for testing. The issue is not really with any missing image. It is with the particular gdkpixbuf2 loader module. Perhaps due to compilation options, link options, or install_name timing during the bundling. However I noticed that compiling gdkpixbuf2 with the loaders built-in did make the problem disappear for me.

Benitoite · 2020-02-23T16:38:17Z

LTO = off was placed into the instructions to let people know they can turn it on if they wish.

Benitoite · 2020-02-24T05:25:02Z

Also, port clang++-mp-9.0 includes clang-mp-9.0
Updates made.

Pandagrapher · 2020-05-16T11:19:27Z

@Benitoite
Hello,
I tried to follow the MacOS compile process in RawPedia with MacPorts (MacOS v10.15.4) but I coped with several issues:

To install dependencies: clang++-mp-9.0 package doesn't exist but clang-9.0 does. cmake should have also been added to work.
To compile: cMake option -DCMAKE_OSX_DEPLOYMENT_TARGET=10.15 is missing otherwise compilation instantly failed.

Otherwise, I still get the following error while linking (it's newlocallabbranch):

[ 80%] Building CXX object rtgui/CMakeFiles/rth.dir/pathutils.cc.o
Undefined symbols for architecture x86_64:
  "_fftwf_cleanup_threads", referenced from:
      rtengine::ImProcFunctions::retinex_pde(float*, float*, int, int, float, float, float*, int, int, int) in librtengine.a(iplocallab.cc.o)
      rtengine::ImProcFunctions::exposure_pde(float*, float*, float*, int, int, float, float) in librtengine.a(iplocallab.cc.o)
      rtengine::ImProcFunctions::fftw_convol_blur(float*, float*, int, int, float, int, int) in librtengine.a(iplocallab.cc.o)
  "_fftwf_init_threads", referenced from:
      rtengine::ImProcFunctions::retinex_pde(float*, float*, int, int, float, float, float*, int, int, int) in librtengine.a(iplocallab.cc.o)
      rtengine::ImProcFunctions::exposure_pde(float*, float*, float*, int, int, float, float) in librtengine.a(iplocallab.cc.o)
      rtengine::ImProcFunctions::fftw_convol_blur(float*, float*, int, int, float, int, int) in librtengine.a(iplocallab.cc.o)
  "_fftwf_plan_with_nthreads", referenced from:
      rtengine::ImProcFunctions::retinex_pde(float*, float*, int, int, float, float, float*, int, int, int) in librtengine.a(iplocallab.cc.o)
      rtengine::ImProcFunctions::exposure_pde(float*, float*, float*, int, int, float, float) in librtengine.a(iplocallab.cc.o)
      rtengine::ImProcFunctions::fftw_convol_blur(float*, float*, int, int, float, int, int) in librtengine.a(iplocallab.cc.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [rtgui/rawtherapee-cli] Error 1
make[1]: *** [rtgui/CMakeFiles/rth-cli.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Do you know what I have missed?
Thanks in advance for your answer,
Pierre

Pandagrapher · 2020-05-17T11:04:06Z

@Benitoite
Finally found the culprit, with MacPorts, fftw-3-single package shall be installed with variant +openmp to contain the missing functions.

Pierre

Benitoite · 2020-05-18T14:13:46Z

Many thanks @Pandagrapher for that.
Added +openmp to the variants.conf section in the wiki.

rfranke · 2020-08-04T18:30:39Z

Encountering the problem with missing -DCMAKE_OSX_DEPLOYMENT_TARGET=10.15 as well. Somehow the automatic detection does not work anymore.

Thanatomanic · 2021-03-22T05:13:02Z

With regards to documentation, please review the contribution of @nomar500 in #6174

nomar500 · 2021-03-24T22:46:20Z

With regards to documentation, please review the contribution of @nomar500 in #6174

For attention and clarity, should I copy-paste my remarks here?

Benitoite · 2021-07-22T22:17:49Z

Added -DCMAKE_OSX_DEPLOYMENT_TARGET=10.15 to the instructions.

jasonliu-- · 2022-01-08T06:14:50Z

Greetings, RawTherapee developers. In November 2021, I packaged RawTherapee for MacPorts, and all of the issues that were discussed in this thread had to be resolved in order to get my package approved. RawTherapee is now an official package available through MacPorts, so your macOS documentation page is now outdated. Users only need to execute a single command:

sudo port install rawtherapee

in order to install RawTherapee using MacPorts. There's no longer any need to manually install any of RawTherapee's dependencies, because as an official package, rawtherapee will automatically install any dependencies that it needs (with a few exceptions... see P.S. below).

P.S.: The actual command is a bit more complicated than the above. As your current documentation points out, if users want to use RawTherapee with Quartz and OpenMP support, they need to install some of the dependencies with specific variants. So the full MacPorts command, on a system with a newly-installed MacPorts, would be (line breaks added for ease of reading):

sudo port install \
  gtk3 -x11 +quartz \
  gtkmm3 -x11 +quartz \
  fftw-3 +openmp \
  fftw-3-single +openmp \
  rawtherapee

One more thing I wanted to point out. Adding +quartz -x11 -gnome +openmp to /opt/local/etc/macports/variants.conf, as stated in your current documentation, is generally not recommended, since this makes them the global settings on the computer, and forces port install commands to override the packages' default variants, which could break other packages that might rely on X11 or GNOME. The variants.conf file is typically used to set a specifically-desired version of languages or compilers for which there are multiple version numbers available, e.g. +python39 +clang11 +lua53 +gcc10 +perl5.32 etc. This ensures that, for example, all packages that get installed will automatically get installed with the +python39 variant, if a particular package has multiple python variants available; thus, even if a package still has +python37 as its default variant, the variants.conf setting will allow the user to install the +python39 variant without needing to manually override the python variant in each of their port install commands.

Benitoite · 2022-01-08T16:44:37Z

@jasonliu 5.8 is very very very outdated. The discussion at hand is compilation of the dev branch using macports, homebrew, or from scratch.

jasonliu-- · 2022-01-08T18:56:44Z

@jasonliu 5.8 is very very very outdated. The discussion at hand is compilation of the dev branch using macports, homebrew, or from scratch.

If it's very outdated, then the devs should consider publishing a new tagged release. MacPorts (and most other package management systems) only allow packages to be based on stable, archived tagged releases. I suppose I could put together a rawtherapee-devel package that is based off the current master, but that certainly wouldn't be a replacement for the rawtherapee package, in my opinion.

In addition, nowhere on the macOS page, or the Linux guide that the macOS page refers to, is it made clear that the pages are intended for developers who want to do development on the dev branch source code. Yes, I'm aware of the "Choose a branch" section of the Linux guide... but that's not what I'm talking about. It seems that the entire macOS and Linux pages are written for developers who want to compile from source, but Google searches for "rawtherapee macos" places the macOS page quite high up in the search results:

When the pages don't clearly label that their intended audience is for developers, it's very easy for regular users who are simply trying to find the software to mistakenly assume that those are the instructions for how to obtain the software. (This is especially true when you consider that it is very difficult to control how Google displays search results, even for a website that you run.) Other software projects make it more clear that the pages on compiling from source are intended for developers, e.g.:

The fact that the discussion at hand is regarding compilation of the dev branch also doesn't change the point I made about the advice that the macOS page provides regarding usage of the variants.conf file. You even make reference to variants.conf later in the page:

The recommended usage of MacPorts variants is given here: https://guide.macports.org/chunked/using.variants.html

Lawrence37 · 2022-01-08T19:57:00Z

@jasonliu--

We've been wanting to publish a new release for many months now. Hopefully there will be no more delays and 5.9 will be released soon.

The macOS page is not just intended for developers. Users may wish to compile RawTherapee themselves for one of many reasons. For example, to make a fast native build. We cannot easily control what Google puts in their search results. What I propose is changing the compilation page titles to "Compiling on macOS/Linux/Windows" or similar.

Thanatomanic · 2022-01-08T20:17:09Z

@jasonliu-- I'm torn between being happy you put RT on MacPorts (:+1:) and being slightly annoyed that you feel misguided by RawPedia and Google, while you seem to have completely misinterpreted the very first sentence of the macOS article and deliberately chose to ignore the higher-up Downloads link the Google search result provided.

It is literally the first sentence on the page that tells you the article is about compiling and nothing at all hints that this is the regular way of obtaining a macOS version of RT... Perhaps this can be further clarified, but I definitely don't think many users make this mistake and simply go to the Downloads page to get things working on macOS (although, using modern hardware and macOS versions this may be trickier...).

In any case, I'm no macOS expert so I cannot judge whether your MacPorts port is in any way useful. However, if we need to update our documentation or download page somehow, feel free to point me in the right direction.

Benitoite · 2022-01-09T06:00:24Z

ATM, macports is not providing pangomm-2.42.1_0+quartz.darwin_21.arm64.tbz2 and fails to build it on Monterey 12.2ß21D5025f (arm64).

As far as the @jasonliu-- portfile: The actual port doesn't seem to get through the dependencies install also: https://ports.macports.org/port/rawtherapee/details/
The default install condition should be changed to Quartz with OpenMP, thereby avoiding the X11 system and allowing more than one core to run threads. The rawtherapee.com builds are built for Quartz and use OpenMP threading to maximize performance.

Honestly the whole macports section of the macos compilation page was unofficially deprecated and left alone a while back when homebrew usage outgrew macports among the other Apple folk. It's inherited legacy material to be sure, we just try to keep it tidy and let it hang out there.

jasonliu-- · 2022-01-13T17:46:42Z

As far as the @jasonliu-- portfile: The actual port doesn't seem to get through the dependencies install also: https://ports.macports.org/port/rawtherapee/details/ The default install condition should be changed to Quartz with OpenMP, thereby avoiding the X11 system and allowing more than one core to run threads. The rawtherapee.com builds are built for Quartz and use OpenMP threading to maximize performance.

The reason why the dependencies are failing to install is because MacPorts' buildbot builders aren't able to install dependencies with variants other than the default variants. IIRC, that topic been brought up a couple of times on our dev mailing list, but none of the core MacPorts devs have taken any action so far. It's kind of a pity, because it makes packages like RT look like they're horribly broken, when they actually will in fact install fine on most people's computers.

Regarding the problem with pangomm on Monterey/arm64, I will get in touch with the maintainers of the pangomm MacPorts package, and see whether they can fix the quartz support on arm64.

Honestly the whole macports section of the macos compilation page was unofficially deprecated and left alone a while back when homebrew usage outgrew macports among the other Apple folk. It's inherited legacy material to be sure, we just try to keep it tidy and let it hang out there.

That's too bad. It may seem like there aren't many MacPorts users out there, but that's because we only collect telemetry on users that opt in to having their data collected; homebrew is the inverse, and automatically collects Google Analytics data unless users opt out.

jasonliu-- · 2022-01-13T18:11:19Z

@Benitoite, I have submitted a MacPorts ticket regarding pangomm failing to build with +quartz on Monterey/arm64:

https://trac.macports.org/ticket/64430

as well as tickets for making +quartz and +openmp the default variants for RT's dependencies:

Thanatomanic added the os: macOS Specific to macOS label Jan 6, 2020

Beep6581 added scope: compilation Compilation issues scope: distribution Software packaging and distribution labels Jan 24, 2020

Beep6581 added this to the v5.8 milestone Jan 24, 2020

Beep6581 added the external: RawPedia label Jan 24, 2020

Beep6581 modified the milestones: v5.8, v5.9 Jan 26, 2020

Beep6581 modified the milestones: v5.9, v6.0 Nov 29, 2022

Lawrence37 modified the milestones: v6.0, v5.11 Apr 20, 2024

Lawrence37 modified the milestones: v5.11, v5.12 Sep 1, 2024

Update documentation for compilation under macOS #5590

Update documentation for compilation under macOS #5590

Comments

rfranke commented Dec 31, 2019 • edited Loading

heckflosse commented Dec 31, 2019

rfranke commented Dec 31, 2019 • edited Loading

heckflosse commented Jan 1, 2020 • edited Loading

rfranke commented Jan 1, 2020

heckflosse commented Jan 1, 2020

rfranke commented Jan 1, 2020

heckflosse commented Jan 1, 2020

rfranke commented Jan 1, 2020

learmj commented Jan 1, 2020

rfranke commented Jan 1, 2020

learmj commented Jan 1, 2020 via email

rfranke commented Jan 2, 2020 • edited Loading

Benitoite commented Jan 4, 2020 • edited Loading

rfranke commented Jan 4, 2020

Benitoite commented Jan 4, 2020 • edited Loading

Beep6581 commented Jan 24, 2020

rfranke commented Jan 25, 2020

Beep6581 commented Jan 25, 2020

Benitoite commented Jan 25, 2020 via email

rfranke commented Jan 25, 2020

Benitoite commented Feb 21, 2020 • edited Loading

rfranke commented Feb 23, 2020 • edited Loading

Benitoite commented Feb 23, 2020

Benitoite commented Feb 23, 2020

Benitoite commented Feb 24, 2020

Pandagrapher commented May 16, 2020

Pandagrapher commented May 17, 2020 • edited Loading

Benitoite commented May 18, 2020

rfranke commented Aug 4, 2020

Thanatomanic commented Mar 22, 2021

nomar500 commented Mar 24, 2021

Benitoite commented Jul 22, 2021

jasonliu-- commented Jan 8, 2022 • edited Loading

Benitoite commented Jan 8, 2022

jasonliu-- commented Jan 8, 2022

Lawrence37 commented Jan 8, 2022

Thanatomanic commented Jan 8, 2022

Benitoite commented Jan 9, 2022 • edited Loading

jasonliu-- commented Jan 13, 2022

jasonliu-- commented Jan 13, 2022

rfranke commented Dec 31, 2019 •

edited

Loading

rfranke commented Dec 31, 2019 •

edited

Loading

heckflosse commented Jan 1, 2020 •

edited

Loading

rfranke commented Jan 2, 2020 •

edited

Loading

Benitoite commented Jan 4, 2020 •

edited

Loading

Benitoite commented Jan 4, 2020 •

edited

Loading

Benitoite commented Feb 21, 2020 •

edited

Loading

rfranke commented Feb 23, 2020 •

edited

Loading

Pandagrapher commented May 17, 2020 •

edited

Loading

jasonliu-- commented Jan 8, 2022 •

edited

Loading

Benitoite commented Jan 9, 2022 •

edited

Loading