Fix linking with libtiff when libtiff is compiled with CMake #1360
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The problem is that we are trying to link against TIFF_LIBRARY. However, according to the documentation for FindTIFF.cmake, we should be using TIFF_LIBRARIES. (https://github.com/Kitware/CMake/blob/master/Modules/FindTIFF.cmake). Why is it this way? It was set this way in commit 0328691 where the message was: > From Sherman Wilcox, "there's a bug in the cmake file for the tiff plugin. See > attached. The problem was that the output files were not properly > setting the debug/release libs due to this cmake bug. What occurred was > the release lib was set in all configurations." Sadly, that commit was form 2010 and I cannot find the attachment since it appears to predate the use of GitHub. I can hope, however, that whatever the CMake issue was, it was fixed in the 15 years since that commit. The reason to make this change is because while using TIFF_LIBRARY works if libtiff is compiled with autotools, it fails if libtiff is compiled with CMake. The reason is subtle. When, libtiff is compiled with autotools, it will be located by CMake using FindTIFF.cmake (https://github.com/Kitware/CMake/blob/master/Modules/FindTIFF.cmake). That module will first attempt to find libtiff using CMake configuration files, but, when that fails, falls back to calling find_library() to locate libtiff. Aftwards, it calls select_library_configurations() which set the TIFF_LIBRARY variable. And so, things work fine. However, if libtiff is compiled with CMake, FindTIFF.cmake will be successful in finding the CMake config files and return without every calling select_library_configurations(). As such, TIFF_LIBRARY is not set. When building using GCC and the standard linker on Linux, this doesn't produce an error - but it does result in a shared object with unresolved symbols. When using Clang on Darwin, however, the result is that linking fails due to the unresolved symbols. The net result is that neither works - but it appears on Linux to have succeeded while on Darwin there is a hard failure that breaks the entire build.
DaGenix
pushed a commit
to DaGenix/nixpkgs
that referenced
this pull request
Feb 23, 2025
The pull request on OpenSceneGraph contains an explanation of why this is necessary: openscenegraph/OpenSceneGraph#1360. This fixes compiling on Darwin, which was broken by the change to have libtiff compiled with CMake in 8b72443 which was merged as part of NixOS#366566.
13 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The problem is that we are trying to link against TIFF_LIBRARY. However, according to the documentation for FindTIFF.cmake, we should be using TIFF_LIBRARIES.
(https://github.com/Kitware/CMake/blob/master/Modules/FindTIFF.cmake).
Why is it this way? It was set this way in commit
0328691 where the message was:
Sadly, that commit was form 2010 and I cannot find the attachment since it appears to predate the use of GitHub. I can hope, however, that whatever the CMake issue was, it was fixed in the 15 years since that commit.
The reason to make this change is because while using TIFF_LIBRARY works if libtiff is compiled with autotools, it fails if libtiff is compiled with CMake.
The reason is subtle. When, libtiff is compiled with autotools, it will be located by CMake using FindTIFF.cmake
(https://github.com/Kitware/CMake/blob/master/Modules/FindTIFF.cmake). That module will first attempt to find libtiff using CMake configuration files, but, when that fails, falls back to calling find_library() to locate libtiff. Aftwards, it calls select_library_configurations() which set the TIFF_LIBRARY variable. And so, things work fine.
However, if libtiff is compiled with CMake, FindTIFF.cmake will be successful in finding the CMake config files and return without every calling select_library_configurations(). As such, TIFF_LIBRARY is not set.
When building using GCC and the standard linker on Linux, this doesn't produce an error - but it does result in a shared object with unresolved symbols. When using Clang on Darwin, however, the result is that linking fails due to the unresolved symbols. The net result is that neither works - but it appears on Linux to have succeeded while on Darwin there is a hard failure that breaks the entire build.