Build failure on GCC/MinGW (MXE): std::ifstream constructor mismatch with Platform::filenameToUTF()

[hkunz]

Description

OpenColorIO 2.5.1 fails to compile under GCC / MinGW-w64 (including MXE cross builds) due to inconsistent file path type handling in Platform::filenameToUTF() when used with std::ifstream in FileTransform.cpp.

The failure occurs when constructing a std::ifstream from the result of Platform::filenameToUTF(filepath), where the returned type may vary between std::string and std::wstring depending on build configuration (_WIN32 && UNICODE).

This leads to template overload resolution failures under GCC/libstdc++ when a std::wstring is involved in std::ifstream construction.

Error observed (GCC / libstdc++)

error: no matching function for call to
std::basic_ifstream<char>::basic_ifstream(const std::wstring, std::ios_base::openmode)

Affected code src/OpenColorIO/transforms/FileTransform.cpp:

std::ifstream(Platform::filenameToUTF(filepath), mode)

Root cause

• Platform::filenameToUTF() is conditionally typed:
• std::wstring on _WIN32 && UNICODE
• std::string otherwise
• std::ifstream construction from std::wstring is not consistently supported across standard library implementations
• GCC/libstdc++ rejects this usage, while MSVC may accept it depending on STL implementation details
• This creates a portability issue in file I/O path handling

Impact

• Breaks MXE / MinGW-w64 cross compilation
• Causes divergence between MSVC and GCC builds
• Introduces non-portable file path handling in core I/O utilities

Suggested fix

Avoid passing platform-dependent string types directly into std::ifstream construction.

This is the C++17-compatible solution that worked:

auto path = Platform::filenameToUTF(filepath);
return std::make_unique<std::ifstream>(path.c_str(), mode);