A recent change ( #2444 ) changed the way the vendored libOpenJPH is pulled into the project in order to avoid a dependency on it.
#2444 appears to turn the vendored OpenJPH into an object library (compiles into a pile of object files) and then adds it to the main OpenEXR core by executing the following cmake:
target_sources(OpenEXRCore PRIVATE $<TARGET_OBJECTS:openjph>)
Under normal circumstances, this would work fine, as the object files for openjph would be added to the OpenEXRCore library as if they were native parts of that library. Unfortunately, this runs into a currently open bug in CMake:
https://gitlab.kitware.com/cmake/cmake/-/work_items/20501
Basically, libOpenJPH has two files with the same name and a different extension:
src/external/OpenJPH/src/core/others/ojph_mem.c
src/external/OpenJPH/src/core/others/ojph_mem.cpp
On all other generators, these two objects would become
ojph_mem.c.o
ojph_mem.cpp.o
but unfortunately, xcode tries to turn them both into ojph_mem.o, and deduplicates the output file name by adding a random hashed unpredictable suffix, something like ojph_mem.2131312312312312.o for the first one, and a different hash for the other (so neither of them end up as just ojph_mem.o
The bug in CMake means it cannot predict what this suffix, and thus all builds fail due to it generating a linker command that simply depends on ojph_mem.o which won't exist.
I'm not actually sure what to do about this, except wait for cmake to fix this, but considering its been active since 2020, we might want a different approach...? For now, in my use case (Open 3D Engine), I might custom build openjph and use a custom built version of it instead of the vendored version. One option might be to patch the vendored openjph or modify it upstream to avoid the name collision.
In o3de's package system, temporarily, I'm just renaming the C file to ojph_mem_c.c as a post-fetch-patch, since the files are pulled in by GLOB.
A recent change ( #2444 ) changed the way the vendored libOpenJPH is pulled into the project in order to avoid a dependency on it.
#2444 appears to turn the vendored OpenJPH into an object library (compiles into a pile of object files) and then adds it to the main OpenEXR core by executing the following cmake:
Under normal circumstances, this would work fine, as the object files for
openjphwould be added to theOpenEXRCorelibrary as if they were native parts of that library. Unfortunately, this runs into a currently open bug in CMake:https://gitlab.kitware.com/cmake/cmake/-/work_items/20501
Basically, libOpenJPH has two files with the same name and a different extension:
On all other generators, these two objects would become
but unfortunately, xcode tries to turn them both into
ojph_mem.o, and deduplicates the output file name by adding a random hashed unpredictable suffix, something likeojph_mem.2131312312312312.ofor the first one, and a different hash for the other (so neither of them end up as justojph_mem.oThe bug in CMake means it cannot predict what this suffix, and thus all builds fail due to it generating a linker command that simply depends on
ojph_mem.owhich won't exist.I'm not actually sure what to do about this, except wait for cmake to fix this, but considering its been active since 2020, we might want a different approach...? For now, in my use case (Open 3D Engine), I might custom build openjph and use a custom built version of it instead of the vendored version. One option might be to patch the vendored openjph or modify it upstream to avoid the name collision.
In o3de's package system, temporarily, I'm just renaming the C file to ojph_mem_c.c as a post-fetch-patch, since the files are pulled in by GLOB.