macOS builds requires libx11

[mcoliver]

Following a rvbuild and then rvinst, I took the resulting RV.app and tried to run it on a clean macOS machine. The result was a crash with the following error about not being able to find libx11. Of course a brew install libx11 will fix this but we want a binary that is standalone and portable.

Termination Reason:  Namespace DYLD, Code 1, Library missing
Library not loaded: /opt/homebrew/*/libX11.6.dylib
Referenced from: <0ED96051-41C3-3299-89DE-0C351AB9CA81> /Users/USER/Downloads/*/RV.app/Contents/lib/libavutil.60.dylib
Reason: tried: '/opt/homebrew/*/libX11.6.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/*/libX11.6.dylib' (no such file), '/opt/homebrew/*/libX11.6.dylib' (no such file)
(terminated at launch; ignore backtrace)

[mcoliver]

You can also verify the link via:

otool -L RV.app/Contents/lib/libavutil.dylib | grep homebrew

[cedrik-fuoco-adsk]

Hello,

Is that with CY2024 or another year?

[mcoliver]

I believe all years. Most likely related to my local dev environment which is not clean (as opposed to github action runners). I'm also seeing linking from the OIIO library to things in homebrew.

This is related to previous issues I have had with building when having certain packages installed via homebrew (eg ffmpeg, openexr, opencolorio) where cmake finds and links to homebrew packages rather than static ones defined by rv cmake files. Which of course affects portability. For an example see below.

I believe I have a fix for ffmpeg and will push a PR once the build is validated. Need to take a look at the OIIO cmake to see why it's preferring homebrew instead of the bundled ffmpeg.

Curious if you have explored having a build option that actually encourages brew install packages (libtiff, libraw, openexr, opencolorio, openimageio, etc..) which should drastically improve build times and decrease package size, though perhaps at the expense of deterministic dependency version control that aswf seemingly wants for some reason that I don't quite understand for a standalone binary like openrv. Leveraging homebrew for dependencies may actually be a good thing by keeping up with the latest dependencies automagically. Maybe this should be its own thread.

./libOpenImageIO.2.5.dylib:
	@rpath/libOpenImageIO.2.5.dylib (compatibility version 2.5.0, current version 2.5.19)
	@rpath/libOpenImageIO_Util.2.5.dylib (compatibility version 2.5.0, current version 2.5.19)
	/opt/homebrew/opt/ffmpeg/lib/libavcodec.62.dylib (compatibility version 62.0.0, current version 62.11.100)
	/opt/homebrew/opt/ffmpeg/lib/libavformat.62.dylib (compatibility version 62.0.0, current version 62.3.100)
	/opt/homebrew/opt/ffmpeg/lib/libavutil.60.dylib (compatibility version 60.0.0, current version 60.8.100)
	/opt/homebrew/opt/ffmpeg/lib/libswscale.9.dylib (compatibility version 9.0.0, current version 9.1.100)
	/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.8)
	@rpath/libpng16.16.dylib (compatibility version 16.0.0, current version 16.48.0)
	@rpath/libz.dylib (compatibility version 1.0.0, current version 1.3.1)
	@rpath/libopenjp2.7.dylib (compatibility version 7.0.0, current version 2.5.0)
	@rpath/libOpenEXR-3_3.32.dylib (compatibility version 32.0.0, current version 32.3.3)
	@rpath/libOpenEXRCore-3_3.32.dylib (compatibility version 32.0.0, current version 32.3.3)
	@rpath/libraw_r.23.dylib (compatibility version 24.0.0, current version 24.0.0)
	/opt/homebrew/opt/jpeg-turbo/lib/libjpeg.8.dylib (compatibility version 8.0.0, current version 8.3.2)
	@rpath/libboost_thread.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libImath-3_1.29.dylib (compatibility version 29.0.0, current version 29.11.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
	@rpath/libIlmThread-3_3.32.dylib (compatibility version 32.0.0, current version 32.3.3)
	@rpath/libIex-3_3.32.dylib (compatibility version 32.0.0, current version 32.3.3)
	@rpath/libtiff.6.dylib (compatibility version 6.0.0, current version 6.0.2)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 2000.67.0)

[cedrik-fuoco-adsk]

It's odd for FFmpeg because we do have USE_FFMPEG=0 in oiio.cmake to prevent OIIO from using it. OIIO might still be linking to it without using it.

We are planing to explore possibilities to reduce build times (which should include something along what you said), but there is no timeline or guarantee currently.