OCIO 2.4.2 FTBFS with MinGW
2.4.2 no longer builds using the MinGW toolchain:
https://github.com/msys2/MINGW-packages/actions/runs/13943135122/job/39024134626?pr=23719#step:10:596
The change that broke seems to be related to https://github.com/AcademySoftwareFoundation/OpenColorIO/pull/2112 @cozdas
P.S. Please consider adding MSYS2 to your CI, as there unfortunately seems to be new issues/regressions on every release recently...
FWIW, the following restores the behaviour before the change and makes it build again:
--- a/src/OpenColorIO/transforms/FileTransform.cpp
+++ b/src/OpenColorIO/transforms/FileTransform.cpp
@@ -218,7 +218,7 @@ std::unique_ptr<std::istream> getLutData(
// Default behavior. Return file stream.
return std::unique_ptr<std::istream>(new std::ifstream(
- Platform::filenameToUTF(filepath), mode));
+ Platform::filenameToUTF(filepath).c_str(), mode));
}
bool CollectContextVariables(const Config &,
Interestingly, even MS don't list wstring& as a possible argument for the constructor, but neither do they mention string& since C++11, and they must have wrapped both w/ implicit c_str() calls (don't have access to MSVC headers to confirm). I've checked GCC and LLVM headers, and indeed only the char*, wchar_t* and string& definitions are there (w/ implicit c_str() on string args in underlying basic_filebuf), no wstring&.
I suggest to add back the explicit c_str() for maximum portability.