Mono prevents a compilation of libimage on OSX

[roentgen]

find_package() uses to look for libpng/libjpeg may look Mono.framework/Headers/ out.
Mono.framework/Headers has png.h and tiffio.h on the directory, this cause an ijection of priority path for tiffio.h since it needs dedicate libtiff for it.

Environment: OSX installed Mono framework

[roentgen]

For the issue, I'm working in progress in this branch: https://github.com/opentoonz/opentoonz/tree/fix-cmake-osx

[mich181189]

I've got a fix for the libtiff issue on #85 - make sure the tiff path is at the beginning of the include list.

[roentgen]

I think that's easy way. But we'll have to take care of the order of include paths among (future) fixes.

2nd option: Offering custom FindJPEG.cmake and FindPNG.cmake can exclude unexpected path (such as Mono)
I'm trying to this in https://github.com/opentoonz/opentoonz/tree/fix-cmake-osx

3rd option: We'll get thirdparty/tiff-4.0.3(customized) distinguishable much clearly from other libtiff.

Which option is better for us?

[roentgen]

oh, Mono's libpng is old(1.2.47), and it's not proper version!

[mich181189]

I don't think excluding "unexpected" paths in general is a good idea. Taking jpeg and tiff from mono is fine if it works and if not, cmake find modules usually allow you to hint at where you want to find it if you have a load of different versions around.

Your modification to FindTIFF.cmake is probably a good move though.

In summary, I think this is only really a problem when you have a custom modified library like this. In summary I don't think we should be trying to get too magical with this.

[mich181189]

@roentgen your PNG change, for example, stops it finding the system PNG on OSX (and probably on other platforms, e.g linux) which is maybe not what we want here.

[roentgen]

@mich181189 could you let me see the error?

cmake find modules usually allow you to hint at where you want to find it if you have a load of different versions around.

It looks that find_package()'s config mode does not work for me.
Could you tell me how to give a hint to find_package() without PNGConfig.cmake?

In the module mode, I wrote the small test to share the case,

project(findpng)
find_package(PNG 1.6 REQUIRED)
message("find_package(PNG 1.6 REQUIRED): " ${PNG_INCLUDE_DIRS})

find_package() will fails despite existing /usr/local/Cellar/libpng/1.6.13 and /usr/local/include/libpng16.

project(findpng)
find_package(PNG)
message("find_package(PNG): " ${PNG_INCLUDE_DIRS})

It looks like ok, found "/Library/Frameworks/Mono.framework/Headers/opt/local/include".

[roentgen]

ok, making all controllable is not easy way.
I'll take your fix. Thank you!

[odysseywestra]

Closing in favor of PR #85. Please leave future comments about editing the pull request there.

[roentgen]

I tried PR #85 to merge.
But it does not affect to this issue.
Reopend.

[roentgen]

cd /Users/roentgen/projects/opentoonz/toonz/build/image && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DIMAGE_EXPORTS -DMACOSX -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_SHARED -DTNZIMAGE_DLL -D_USRDLL -Di386 -Dimage_EXPORTS -I/Users/roentgen/projects/opentoonz/toonz/build/image -I/Users/roentgen/projects/opentoonz/toonz/sources/image -I/Users/roentgen/projects/opentoonz/thirdparty -I/Users/roentgen/projects/opentoonz/toonz/sources/include -I/usr/local/Cellar/boost155/1.55.0_1/include -I/usr/local/Cellar/lz4/r131/include -I/usr/local/Cellar/libusb/1.0.20/include/libusb-1.0 -I/usr/local/Cellar/superlu43/4.3_1/include/superlu/superlu -I/Library/Frameworks/Mono.framework/Headers -I/Users/roentgen/projects/opentoonz/thirdparty/LibJPEG/jpeg-9 -iframework /Users/roentgen/Qt/5.5/clang_64/lib -isystem /Users/roentgen/Qt/5.5/clang_64/lib/QtCore.framework/Headers -isystem /Users/roentgen/Qt/5.5/clang_64/./mkspecs/macx-clang -isystem /Users/roentgen/Qt/5.5/clang_64/lib/QtNetwork.framework/Headers -m64 -std=c++11 -stdlib=libc++ -fno-implicit-templates -Wl,-install_name,@rpath/libimage.dylib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -fPIC -fPIC -o CMakeFiles/image.dir/tif/tiio_tif.cpp.o -c /Users/roentgen/projects/opentoonz/toonz/sources/image/tif/tiio_tif.cpp

[mich181189]

According to the cmake docs, PNG_PATH set as an environment variable should do the trick. See https://cmake.org/cmake/help/v3.0/command/find_package.html for the search order used.

[kogaki]

@roentgen With passing -DPNG_PNG_INCLUDE_DIR to cmake and litte fix #151, I finally build OpenToonz successfully. Could you try it? Of course we need easier way. This is just a workaround.

[roentgen]

Good to be able to share the problem.
I'd like to try it after ... when my boss is out of office.

[ghost]

Is this still an issue or can it be closed?

[ghost]

I still get this error with the current repository. I use mac 10.12.4, qt5.8. Other settings are the same with the installation document of macox. Thanks.

[ghost]

I updated the build for Mac OS. It should work now- I ran into the same issue and (think) I fixed it. I'm going to close this. If it is still an issue, we can reopen or create a new issue.

[sctar]

I'm still having this problem and the workaround in #151 does not seem to fix it.

[tailsu]

Mono.framework causes CMake to produce an incorrect build due to libpng and libjpeg.

CMake has this funny parameter called CMAKE_FIND_FRAMEWORK which is set by default to FIRST. This means that CMake will first look for files first in all framework directories, and only then in regular include directories. Funnily enough Mono.framework contains the headers for libjpeg and libpng. So, CMake finds the headers in Mono, but the library in the regular install location, e.g. /usr/local/lib and therefore a version mismatch happens.

Mono is a known menace (for some time brew doctor warned if Mono is installed that builds may fail). You can see this behavior if you create a CMakeLists.txt file with the single line find_package(JPEG), run cmake . and take a look at the paths in the generated CMakeCache.txt file.

The fix that definitively worked for me was to check out the project manually, add set(CMAKE_FIND_FRAMEWORK LAST) to CMakeLists.txt before the find_package calls and then run luarocks make. This way CMake found the headers in the right folder.