Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

opencolorio: update to 2.4.1 #22697

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

opencolorio: update to 2.4.1 #22697

wants to merge 2 commits into from

Conversation

kmilos
Copy link
Contributor

@kmilos kmilos commented Nov 29, 2024

No description provided.

@kmilos
Copy link
Contributor Author

kmilos commented Nov 29, 2024

Reported upstream.

@kmilos kmilos changed the title opencolorio: update to 2.4.0 opencolorio: update to 2.4.1 Dec 13, 2024
@kmilos
Copy link
Contributor Author

kmilos commented Dec 13, 2024

New hurdle after patching:

D:/M/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib/libbf_intern_ghost.a(GHOST_Context.cc.obj):GHOST_Context.:(.text+0xc6): undefined reference to `__ms_fprintf'

(and similarly ld.lld: error: undefined symbol: __ms_fprintf for CLANG64)

Related to some recent mingw-w64 CRT update? blender was successfully bumped just 3 weeks ago, and MINGW64 still builds...

MehdiChinoune referenced this pull request in mingw-w64/mingw-w64 Dec 14, 2024
…ctions

Ensure that all these MS specific _*t* macros always expands to MS variant
of scanf and printf functions independently of __USE_MINGW_ANSI_STDIO.

Majority of the _*t* macros expands to MS specific variants of stdio
functions which are not provided by mingw when __USE_MINGW_ANSI_STDIO=1.

But some few are, e.g. _tscanf which currently expands to scanf or wscanf.
And this can cause that _tscanf behaves differently than _tscanf_l (which
does not have __USE_MINGW_ANSI_STDIO=1 replacement.

Another example is %s in _stprintf() macro. MS variant of wide-printf
treats %s as wchar_*t, but C95+ mandates that %s is always char*.

_stprintf() is suppose to be called as:

  _stprintf(buffer, _T("%s"), _T("string"));

And wide variant would work correctly only in the case %s takes wchar_t*.

With this change behavior of all _*t* macros would be same and expands
always only to MS function, which also ensures compatibility of %s with
arguments passed to _*t* macros.

Signed-off-by: Martin Storsjö <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant