xsscx
commented
6 months ago iccProfLib uses C++11 features (e.g. {} syntax for object initialisation), but the projects use the Xcode default for C++ dialect, which is C++98.
DH For the Xcode Projects and my PR's, the Dialect is (should be) configured for c++17 which is specified in Build/Cmake/CMakeLists.txt
iccProfLib also contains invalid code, that casts enums to integers and tries to use values outside their valid range (e.g. in GetMeasurementFlareName) which is undefined behaviour. Clang errors on this by default, which can technically be silenced with -Wno-enum-constexpr-conversion although that's not a real solution (Clang doesn't guarantee the runtime behaviour will be as the code expects) and a performance pessimisation.
DH Issue was addressed in https://github.com/InternationalColorConsortium/DemoIccMAX/pull/66
Beyond that, the iccProfLib builds as x86-64 only but all the subprojects (e.g. IccApplyNamedCmm) use the default value for the target architectures (which is currently x86_64 and arm64). So they all fail to link due to the missing arm64 slice.
DH The Issue arises because Brew installs the Platform arch Slice of the Host, not a Universal Binary. PR in process to automagically build LibXML2 and LibTIFF Universal Binaries for XNU Platform and then create same for DemoIccMAX Project Libs and Tools. There is a Build Script in Build/Xcode that you can modify to build either slice using -arch x86_64 or -arch arm64. You can also rebuild the Xcode Project File.
cd Build
../contrib/HelperScripts/libtiff_build.zsh
../contrib/HelperScripts/libxml2_build.zsh
mkdir xcode_build
cd xcode_build
cmake -G Xcode ../Cmake
open RefIccMAX.xcodeprojOr just build on the command line:
cd Build/
../contrib/HelperScripts/libtiff_build.zsh
../contrib/HelperScripts/libxml2_build.zsh
cmake -DCMAKE_INSTALL_PREFIX=$HOME/.local -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS="-g -fsanitize=address,undefined -fno-omit-frame-pointer -Wall" -Wno-dev Cmake
make -j$(nproc) 2>&1 | grep 'error:'RefIccMAXCmm also fails to build because it's using ColorSync types (e.g. CMError) which seemingly don't exist anymore (they were deprecated more than a decade ago, so I assume they've finally be outright removed from the framework).
DH Outlier Datapoint: there is merit to keeping the Code in the Project as anyone can boot back in time and compile.
The macOS deployment target is also being set to (or defaulting to?) 10.11, but modern Xcode doesn't support earlier than 10.13. This nominally just results in a warning, although it's possible it's screwing other things up too (hard to tell with so many other errors occurring in parallel).
DH PR's for Xcode Projects updated the Deployment Targets using sed for the Platforms and matched on DEPLOYMENT_TARGET= for 17.x and 14.x. Will re-check those config options, and for less compile Noise, try using:
make -j$(nproc) 2>&1 | grep 'error:'OR
xcodebuild -project ProjectName__.xcodeproj -scheme ALL_BUILD -configuration Release -destination 'platform=macOS,arch=x86_64' 2>&1 | grep 'error:'IccLibXML.xcodeproj is missing targets for the actual command line tools - IccToXML et al.
DH Is this with respect to IccXML/CmdLine/IccToXml an IccXML/CmdLine/IccFromXml? PR https://github.com/InternationalColorConsortium/DemoIccMAX/pull/75 addressed this issue and those SubProjects have a CMakeLists.txt alllowing for easily rebuilding the Xcode Projects. There are also now Build Scripts provided for both those projects for macOS in IccXML/CmdLine/IccToXml/xnu_build_cmd_IccToXml.zsh and IccXML/CmdLine/IccFromXml/xnu_build_cmd_IccFromXml.zsh.
Update the Issue if can help.
iccProfLib uses C++11 features (e.g.
{}syntax for object initialisation), but the projects use the Xcode default for C++ dialect, which is C++98.iccProfLib also contains invalid code, that casts enums to integers and tries to use values outside their valid range (e.g. in
GetMeasurementFlareName) which is undefined behaviour. Clang errors on this by default, which can technically be silenced with-Wno-enum-constexpr-conversionalthough that's not a real solution (Clang doesn't guarantee the runtime behaviour will be as the code expects) and a performance pessimisation.Beyond that, the iccProfLib builds as x86-64 only but all the subprojects (e.g. IccApplyNamedCmm) use the default value for the target architectures (which is currently x86_64 and arm64). So they all fail to link due to the missing arm64 slice.
RefIccMAXCmm also fails to build because it's using ColorSync types (e.g.
CMError) which seemingly don't exist anymore (they were deprecated more than a decade ago, so I assume they've finally be outright removed from the framework).The macOS deployment target is also being set to (or defaulting to?) 10.11, but modern Xcode doesn't support earlier than 10.13. This nominally just results in a warning, although it's possible it's screwing other things up too (hard to tell with so many other errors occurring in parallel).
IccLibXML.xcodeproj is missing targets for the actual command line tools - IccToXML et al.