Issues Building on MacOS Big Sur (11.4)

Discussion related to the LuxCore functionality, implementations and API.
danielbui78
Posts: 17
Joined: Wed Jun 23, 2021 10:47 pm

Issues Building on MacOS Big Sur (11.4)

Post by danielbui78 »

Hi, I'm trying to build LuxCore on MacOS 11.4 Big Sur using the MacOSCompileDeps and the instructions found here:
https://wiki.luxcorerender.org/Compilin ... acOS_11.2B

Those instructions appear to be working without any error messages on MacOS 11.4 with the default zsh and Xcode 13 and the latest github clone of LuxCore and MacOSCompileDeps, as long as I do three things:

1. I removed "slib" from the initial "brew install" command. Homebrew does not know what this is. Is it a typo?

2. The wrong python version is used (aka pyenv has no effect), until the following command is used:
eval "$(pyenv init --path)"

3. The wrong pip version is used (aka pyenv has no effect), until the following changes are made to .zshrc and the terminal restarted:
https://gist.github.com/josemarimanio/9 ... 63587e80f8 (must also add the above command to the .zshrc)

After those two additions are made to the Compiling Instructions (https://wiki.luxcorerender.org/Compilin ... acOS_11.2B), the entire build and dmg packaging process appears to finish successfully without errors.

However, when I use the binary that I've built, I get the following console error message:

Code: Select all

RUNTIME ERROR: Error opening image file : XXXXX.png (error = Could not create PNG read structure)
I think I have tracked it down to OpenImageIO. There is a similar issue reported on their github system, but apparently it was resolved and closed (https://github.com/OpenImageIO/oiio/issues/2218). I have tried building with the latest commit as well as with the v2.5 / 2.5rc1 tags for LuxCore and MacOSCompileDeps. Both appear to be producing a similar error message. When (Edited) I use the binary built with 2.5, I get this:

Code: Select all

libpng warning: Application built with libpng-1.4.12 but running with 1.6.37
RUNTIME ERROR: Error opening image file : XXXXX.png (error = Could not create PNG read structure)
I'm looking into the libpng-1.4.12 issue -- I have no other installations of libpng installed. I've modified the LuxCore cmake and xcode project files to explicitly link with libpng16.a. My next step is to look through the MacOSCompileDeps dist files for oiio / libpng.

FYI, the precompiled LuxCore binaries work without any error messages.

Has anyone seen this error before? Thanks in advance!
Last edited by danielbui78 on Sat Nov 13, 2021 3:22 pm, edited 1 time in total.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Issues Building on MacOS Big Sur (11.4)

Post by Dade »

danielbui78 wrote: Fri Nov 12, 2021 6:40 pm

Code: Select all

libpng warning: Application built with libpng-1.4.12 but running with 1.6.37
2 issues here:

1) You seem to have a libpng v1.6.37 ".so" somewhere and it used instead of v1.4.12. On Linux, you would have to do a "ldd luxcoreui" to check what libpng DLL is used (no idea if ldd is available on MacOS :?:).

2) libpng should be statically linked so the above message is even more strange. It seems to hint a dynamic liking with a libpng DLL. You may want to check what libpng cmake resolves and compile with.
Support LuxCoreRender project with salts and bounties
danielbui78
Posts: 17
Joined: Wed Jun 23, 2021 10:47 pm

Re: Issues Building on MacOS Big Sur (11.4)

Post by danielbui78 »

Dade wrote: Sat Nov 13, 2021 2:57 pm 2 issues here:

1) You seem to have a libpng v1.6.37 ".so" somewhere and it used instead of v1.4.12. On Linux, you would have to do a "ldd luxcoreui" to check what libpng DLL is used (no idea if ldd is available on MacOS :?:).

2) libpng should be statically linked so the above message is even more strange. It seems to hint a dynamic liking with a libpng DLL. You may want to check what libpng cmake resolves and compile with.
Thanks! I was thinking the same things, but couldn't remember the commands to check dynamic linkage. The MacOS equivalent is "otool -L luxcoreui" (thanks, Google). I ran otool -L against the official distributed LuxCore 2.5 binary and my build, and confirmed that libpng is probably statically linked -- I assume to libOpenImageIO.1.8.dylib. One thing to note: I disabled "Use Shared Libraries" from the LuxCore CMake options, but maybe this is currently unused on the Mac cmake build process?

Regarding libpng versions, MacOSCompileDeps contains and builds libpng version 1.6 (libpng16.a). I modified the LuxCore CMake files and double-checked Xcode project files to explicitly use "libpng16.a" and "include\libpng16" in the compiler/linker arguments, but I'm still getting the same warning/error message. My next step is to modify the build scripts for MacOSCompileDeps so that it does not erase the evidence of when it completes building of each dependency library. I'll then start searching through OpenImageIO to see if there's an extra copy of libpng hidden inside its tarball.

FYI, here is the otool -L outputs for comparison:
Official LuxCore 2.5 distributed binaries which fully work without PNG errors:

Code: Select all

luxcoreui:
	@executable_path/../Resources/libs/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1673.126.0)
	/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
	@executable_path/../Resources/libs/libembree3.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	@executable_path/../Resources/libs/libOpenImageDenoise.1.2.1.dylib (compatibility version 0.0.0, current version 1.2.1)
	@executable_path/../Resources/libs/libtbb.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/../Resources/libs/libtiff.5.dylib (compatibility version 11.0.0, current version 11.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	@executable_path/../Resources/libs/libOpenImageIO.1.8.dylib (compatibility version 1.8.0, current version 1.8.13)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1894.10.126)
	/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1348.12.4)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1673.126.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

luxcoreconsole:
	@executable_path/../Resources/libs/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
	@executable_path/../Resources/libs/libembree3.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	@executable_path/../Resources/libs/libOpenImageDenoise.1.2.1.dylib (compatibility version 0.0.0, current version 1.2.1)
	@executable_path/../Resources/libs/libtbb.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/../Resources/libs/libtiff.5.dylib (compatibility version 11.0.0, current version 11.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	@executable_path/../Resources/libs/libOpenImageIO.1.8.dylib (compatibility version 1.8.0, current version 1.8.13)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)

libOpenImageIO.1.8.dylib:
	@executable_path/../Resources/libs/libOpenImageIO.1.8.dylib (compatibility version 1.8.0, current version 1.8.13)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	@executable_path/../Resources/libs/libtiff.5.dylib (compatibility version 11.0.0, current version 11.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)
My build from 2.5 tags, which cause PNG errors:

Code: Select all

luxcoreui:
	@executable_path/../Resources/libs/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1775.118.101)
	/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)
	@executable_path/../Resources/libs/libembree3.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	@executable_path/../Resources/libs/libOpenImageDenoise.1.2.1.dylib (compatibility version 0.0.0, current version 1.2.1)
	@executable_path/../Resources/libs/libtbb.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/../Resources/libs/libtiff.5.dylib (compatibility version 11.0.0, current version 11.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	@executable_path/../Resources/libs/libOpenImageIO.1.8.dylib (compatibility version 1.8.0, current version 1.8.13)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1775.118.101)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 905.6.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2022.44.149)
	/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1463.4.2)

luxcoreconsole:
	@executable_path/../Resources/libs/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
	@executable_path/../Resources/libs/libembree3.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	@executable_path/../Resources/libs/libOpenImageDenoise.1.2.1.dylib (compatibility version 0.0.0, current version 1.2.1)
	@executable_path/../Resources/libs/libtbb.dylib (compatibility version 0.0.0, current version 0.0.0)
	@executable_path/../Resources/libs/libtiff.5.dylib (compatibility version 11.0.0, current version 11.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	@executable_path/../Resources/libs/libOpenImageIO.1.8.dylib (compatibility version 1.8.0, current version 1.8.13)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 905.6.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)

libOpenImageIO.1.8.dylib:
	@executable_path/../Resources/libs/libOpenImageIO.1.8.dylib (compatibility version 1.8.0, current version 1.8.13)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	@executable_path/../Resources/libs/libtiff.5.dylib (compatibility version 11.0.0, current version 11.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 905.6.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
PS: Regarding how there is a warning message regarding libpng 1.4 vs 1.6 even though it appears to be statically linked, my current theory is that libpng uses a global static class/object with version information. If OpenImageIO library is static linked to libpng14, while the LuxCore binaries are static linked to libpng16: there may be a namespace collision in the C++ Runtime and the libpng16 static class/object is over-riding libpng14 instance of the same class. This might explain why there is a RUNTIME ERROR when reading PNG in my build of 2.5, but why is the latest 2.6 build reporting the same RUNTIME ERROR without the libpng version mismatch warning?
danielbui78
Posts: 17
Joined: Wed Jun 23, 2021 10:47 pm

Re: Issues Building on MacOS Big Sur (11.4)

Post by danielbui78 »

danielbui78 wrote: Sat Nov 13, 2021 4:10 pm PS: Regarding how there is a warning message regarding libpng 1.4 vs 1.6 even though it appears to be statically linked, my current theory is that libpng uses a global static class/object with version information. If OpenImageIO library is static linked to libpng14, while the LuxCore binaries are static linked to libpng16: there may be a namespace collision in the C++ Runtime and the libpng16 static class/object is over-riding libpng14 instance of the same class. This might explain why there is a RUNTIME ERROR when reading PNG in my build of 2.5, but why is the latest 2.6 build reporting the same RUNTIME ERROR without the libpng version mismatch warning?
I was partly right but mostly wrong. I tracked the problem(s) down to a function named create_read_struct() in "/src/png.imageio/png_pvt.h" in the OpenImageIO source code. This function makes a call to the PNG library function png_create_read_struct() which takes PNG_LIBPNG_VER_STRING as its first argument. libpng then checks the version passed in by the calling application against its own internal version string. This is how libpng checks for "build-time" versus "runtime" library version discrepancies. So png_pvt.h is somehow reading in the wrong png.h at compile time.

However, none of the png.h files on my harddrive are anything other than version 1.6. I'm still in the process of modifying the MacOSCompileDeps/build_deps script and rebuilding so that it does not erase evidence of the build process. Hopefully, I will find the answer in there: maybe an old patch is being applied or a pre-compiled object was not cleaned.
danielbui78
Posts: 17
Joined: Wed Jun 23, 2021 10:47 pm

Re: Issues Building on MacOS Big Sur (11.4)

Post by danielbui78 »

Well this is frustrating and disappointing: I've modified the build_deps so that it doesn't delete the intermediate build files. Nothing seems out of the ordinary. It appears to be referencing the appropriate libpng16 files. The command line output looks OK. There does appear to be a lot of temp folders being created that almost looks like it is downloading nightly builds or something, but they don't have any source or object code files in them. The only thing I can think of to do next is to painstakingly go through each step of the CMake build process to make sure I'm not missing any transient state changes in the files.

If anyone has any suggestions, please let me know.

FYI:

Code: Select all

[ 52%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/__/png.imageio/pnginput.cpp.o
cd /tmp/macdepsbuild/oiio-Release-1.8.13/build/macosx/src/libOpenImageIO && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DBOOST_ALL_NO_LIB -DBoost_USE_STATIC_LIBS=1 -DEMBED_PLUGINS=1 -DOpenImageIO_EXPORTS -DUSE_BOOST_ASIO=1 -DUSE_STD_REGEX -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/tmp/macdepsbuild/oiio-Release-1.8.13/build/macosx/include -I/tmp/macdepsbuild/oiio-Release-1.8.13/src/include -I/Library/Frameworks/Mono.framework/Headers -I/Volumes/Development/GitHub/MacOSCompileDeps/macos/include/OpenEXR -isystem /Volumes/Development/GitHub/MacOSCompileDeps/macos/include -std=c++1z -w -mmmx -mno-sse3 -mno-ssse3 -msse -msse2 -O2 -pipe -mfpmath=sse -fPIC -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -fPIC   -Wall -fno-math-errno -Wno-unused-function -Wno-overloaded-virtual -Wno-unneeded-internal-declaration -Wno-unused-private-field -Wno-tautological-compare -Qunused-arguments -Wunknown-warning-option -Wno-unused-local-typedefs -std=c++11 -Wno-deprecated-register -UUSE_FIELD3D -MD -MT src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/__/png.imageio/pnginput.cpp.o -MF CMakeFiles/OpenImageIO.dir/__/png.imageio/pnginput.cpp.o.d -o CMakeFiles/OpenImageIO.dir/__/png.imageio/pnginput.cpp.o -c /tmp/macdepsbuild/oiio-Release-1.8.13/src/png.imageio/pnginput.cpp

[ 53%] Building CXX object src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/__/png.imageio/pngoutput.cpp.o
cd /tmp/macdepsbuild/oiio-Release-1.8.13/build/macosx/src/libOpenImageIO && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DBOOST_ALL_NO_LIB -DBoost_USE_STATIC_LIBS=1 -DEMBED_PLUGINS=1 -DOpenImageIO_EXPORTS -DUSE_BOOST_ASIO=1 -DUSE_STD_REGEX -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/tmp/macdepsbuild/oiio-Release-1.8.13/build/macosx/include -I/tmp/macdepsbuild/oiio-Release-1.8.13/src/include -I/Library/Frameworks/Mono.framework/Headers -I/Volumes/Development/GitHub/MacOSCompileDeps/macos/include/OpenEXR -isystem /Volumes/Development/GitHub/MacOSCompileDeps/macos/include -std=c++1z -w -mmmx -mno-sse3 -mno-ssse3 -msse -msse2 -O2 -pipe -mfpmath=sse -fPIC -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -fPIC   -Wall -fno-math-errno -Wno-unused-function -Wno-overloaded-virtual -Wno-unneeded-internal-declaration -Wno-unused-private-field -Wno-tautological-compare -Qunused-arguments -Wunknown-warning-option -Wno-unused-local-typedefs -std=c++11 -Wno-deprecated-register -UUSE_FIELD3D -MD -MT src/libOpenImageIO/CMakeFiles/OpenImageIO.dir/__/png.imageio/pngoutput.cpp.o -MF CMakeFiles/OpenImageIO.dir/__/png.imageio/pngoutput.cpp.o.d -o CMakeFiles/OpenImageIO.dir/__/png.imageio/pngoutput.cpp.o -c /tmp/macdepsbuild/oiio-Release-1.8.13/src/png.imageio/pngoutput.cpp

EDIT:
Actually, at this point, I think it would be faster for me just to insert additional debugging output directly into libPNG and OpenImageIO and maybe hardcode a bypass directly into the version checker to see if it works....
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Issues Building on MacOS Big Sur (11.4)

Post by Dade »

Wait a sec, LuxCore v2.5 ? May be you are mixing a version of MacOS dependencies for LuxCore v2.6alpha and and v2.5 sources.

Try to checkout form GitHUB the very last LuxCore sources (aka v2.6alpha), MacOS dependencies, etc. and check if they work.

For reference, pre-compiled v2.6alpha MacOS binaries are available here: viewtopic.php?f=9&t=736
Support LuxCoreRender project with salts and bounties
danielbui78
Posts: 17
Joined: Wed Jun 23, 2021 10:47 pm

Re: Issues Building on MacOS Big Sur (11.4)

Post by danielbui78 »

Dade wrote: Sat Nov 13, 2021 11:04 pm Wait a sec, LuxCore v2.5 ? May be you are mixing a version of MacOS dependencies for LuxCore v2.6alpha and and v2.5 sources.

Try to checkout form GitHUB the very last LuxCore sources (aka v2.6alpha), MacOS dependencies, etc. and check if they work.
Yes, thanks. That's what I tried first -- the latest commit from both LuxCore and MacOSCompileDeps. It was the same RUNTIME ERROR message, just without the version check warning. The OpenImageIO function I mentioned above is the source of both messages. I'm certain there is no mismatch in dependencies, since I tested each separately, removing the previous just to make sure there was no accidental cross-over. And then I hard-coded the absolute path to the library header paths and linker paths of LuxCore Xcode project just to be certain. Unfortunately, no change in error results. It definitely seems to be related to my build process of the dependencies.

For reference, pre-compiled v2.6alpha MacOS binaries are available here: viewtopic.php?f=9&t=736
Great! This pre-compiled binary works without error messages just like the pre-compiled 2.5 binaries. Are mac binaries built from the automated system too? If so, is there a way for me to download the precompiled mac dependencies? I really don't care about building the mac dependencies myself. My main goal is just to get LuxCore built so that I can continue working on my fork and add Mac support.
User avatar
u3dreal
Developer
Developer
Posts: 560
Joined: Tue Dec 03, 2019 3:23 pm
Location: Ulm
Contact:

Re: Issues Building on MacOS Big Sur (11.4)

Post by u3dreal »

The png error comes from an outdated mono framework which includes png ? .. delete that from your /home/Library/Frameworks if it is present.
at least that was when i had this issue. Had it several times when the mono framework was present. Somehow tricked myself.
Second it could be you have duplicate version installed vie Homebrew. uninstall those.

Latest prebuild dependecies can be found here.
https://github.com/LuxCoreRender/MacOSC ... _v2.6alpha

And yes compiling on OSX can be frustrating.

With the right dependencies it should be straigt forward though.

You can find my build scripts for macos here.https://github.com/LuxCoreRender/LuxCor ... ipts/macos

The azur buildscript can be found herehttps://github.com/LuxCoreRender/LuxCor ... line/macos

some changes might be needed especially for the xcode script ... i haven't used it for some time... building with cmake is easier for me.

If you have any further problems let me know.

Be aware that OpenCL seems to be broken ... again in 11.6.1 .. I not sure if 11.4 works or not... if i remember it should but also depends on you GFX driver !

not even the image pipeline OCL will compile .. no idea why ...

The wiki sure needs update but i'm in the process of adding most of the libs as static and i wanted to wait until things work out.
I had some questions for the other devs that were not answered yet. My plan then is to update the wiki as well for BigSur.

Somehow i do not get mailed when i get a message in the forum so it might take time untill i see it.
check out my newest stuff http://q3de.com/research/
portfolio http://q3de.com/


MB Pro i7 2.3Ghz, IrisPro 1.5GB, GTX750m 2GB - BigSur
Xeon X5650@4Ghz, RX 5700 - BigSur , Windows 10, Ubuntu 20.04
epilectrolytics
Donor
Donor
Posts: 790
Joined: Thu Oct 04, 2018 6:06 am

Re: Issues Building on MacOS Big Sur (11.4)

Post by epilectrolytics »

u3dreal wrote: Sun Nov 14, 2021 5:12 am Be aware that OpenCL seems to be broken ... again in 11.6.1 .. I not sure if 11.4 works or not...
No idea about building but latest MacOS BlendLux (from 2 weeks ago) works with 12.0.1 on M1 via Rosetta including OCL rendering, which is great!
danielbui78
Posts: 17
Joined: Wed Jun 23, 2021 10:47 pm

Re: Issues Building on MacOS Big Sur (11.4)

Post by danielbui78 »

u3dreal wrote: Sun Nov 14, 2021 5:12 am The png error comes from an outdated mono framework which includes png ? .. delete that from your /home/Library/Frameworks if it is present....
100%!!! Thanks! That was exactly what and where you described it (In the Frameworks for mono). I had assumed that my spotlight search for "png.h" would be an exhaustive filesystem search, but apparently not. My bad.
Latest prebuild dependecies can be found here.
https://github.com/LuxCoreRender/MacOSC ... _v2.6alpha
OK, looks like a bad trend of overlooking stuff for me. Didn't realize precompiled dependencies were attached to each release. Thanks!
Be aware that OpenCL seems to be broken ... again in 11.6.1 .. I not sure if 11.4 works or not... if i remember it should but also depends on you GFX driver !
Yes, heh... that is why I am using 11.4. The 11.6.1 update broke OpenGL/OpenCL support for my integrated graphics drivers. I just tried upgrading 11.4 to 11.6.0 so that I am not completely vulnerable. OpenGL/OpenCL seems to be working except LuxCore 2.5 is now seg-faulting (may be unrelated to OS upgrade).

I will try to look into the azure build script and testing the xcode support when I have more free time. I can also help with updating wiki instructions for Big Sur (at least for people that use pre-11.6.1).

Thanks again for everyone's patience and help!
Post Reply