OpenColorIO icon indicating copy to clipboard operation
OpenColorIO copied to clipboard

OCIO 2.4.2 FTBFS with MinGW

Open kmilos opened this issue 9 months ago • 1 comments

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...

kmilos avatar Mar 19 '25 09:03 kmilos

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.

kmilos avatar Mar 20 '25 08:03 kmilos