mingw64 libjxl bulid failed

[kliffgomel]

09:07:39 ┌ libjxl git ............................... [Recently updated]
09:09:03 ├ Running cmake...
09:09:11 ├ Running build...
Likely error (tail of the failed operation logfile):
[5/23] Linking CXX static library lib\libjxl_extras-internal.a
[6/23] Linking CXX static library lib\libjxl_extras_codec.a
[7/23] Building RC object tools/CMakeFiles/cjpegli.dir/utf8.rc.obj
FAILED: tools/CMakeFiles/cjpegli.dir/utf8.rc.obj
D:\ffmpeg-autobuild\msys64\mingw64\bin\windres.exe -O coff -DFJXL_ENABLE_AVX512=0 -DHWY_STATIC_DEFINE -DJPEGXL_ENABLE_JPEGLI=1 -DJXL_STATIC_DEFINE -DTOOLCHAIN_MISS_ASM_HWCAP_H -DTOOLCHAIN_MISS_SYS_AUXV_H -D__DATE__="redacted" -D__TIMESTAMP__="redacted" -D__TIME__="redacted" -I D:/ffmpeg-autobuild/build/libjxl-git -I D:/ffmpeg-autobuild/build/libjxl-git/third_party/highway -I D:/ffmpeg-autobuild/build/libjxl-git/lib/include -I D:/ffmpeg-autobuild/msys64/mingw64/include -I D:/ffmpeg-autobuild/build/libjxl-git/third_party/-ID:/ffmpeg-autobuild/msys64/mingw64/include -I D:/ffmpeg-autobuild/build/libjxl-git/build-64bit/lib/include D:/ffmpeg-autobuild/build/libjxl-git/tools/utf8.rc tools/CMakeFiles/cjpegli.dir/utf8.rc.obj
: warning: "DATE" redefined [-Wbuiltin-macro-redefined]
: warning: "TIMESTAMP" redefined [-Wbuiltin-macro-redefined]
: warning: "TIME" redefined [-Wbuiltin-macro-redefined]
D:\ffmpeg-autobuild\msys64\mingw64\bin\windres.exe: can't open file `utf8.manifest': Invalid argument
ninja: build stopped: subcommand failed.
build failed.

logs.zip

[L4cache]

jpegli...?
That's ceased in libjxl repo and migrated into it's own repo...
Probably should just disable it completely...

[nikolasr]

libjxl commit 7b70ef1 is to blame for this.
Quick'n'dirty workaround:
Switch to stable v0.11.x git branch for libjxl
To do so edit your media-suite_deps.sh in your build dir.
Change
SOURCE_REPO_LIBJXL=https://github.com/libjxl/libjxl.git
to
SOURCE_REPO_LIBJXL=https://github.com/libjxl/libjxl.git#branch=v0.11.x

and try again :-)

Remember to undo this workaround when things are fixed upstream :-)

[1480c1]

One thing I am interested in is how -I D:/ffmpeg-autobuild/build/libjxl-git/third_party/-ID:/ffmpeg-autobuild/msys64/mingw64/include got in there.

[1480c1]

It seems to be from the patch we add for brotli linking, as removing the patch removes the malformed include directory, but will instead cause linking issues with brotli

[L4cache]

Somehow, clang64 environment can successfully build it, mingw64 can't

It not limited to jpegli part but jpegli should be disabled (why don't they just remove it completely?)
(with all respect, I love jxl but the claimed advantage of jpegli is nonsensical, mozjpeg is still best/most suitable choice for plain old jpeg, jpegli can be a interesting experiment but is not what google made it sound like)

[L4cache]

Uh, after think it more thoroughly, the jpegli is put in "check list" but is not enabled explicitly, so:

• If we explicit disable it now, if upstream remove it in the future, that will probably result in an extra option not used warning in cmake, not a big deal.

• If we only remove it from "check list" but not explicitly disable it, it will be built by default until upstream remove it.

• If we leave it there, once upstream remove it, there will be Files Missing error in m-ab-s suite.

I think it should be removed from "check list", and probably disable it explicitly (because it will be outdated anyway).

[nikolasr]

Well, why not postpone the decision and just change libjxl code to stable git branch by default for now? Gives us time and does not break anything. With libjxl set to stable everything compiles well for me at MinGW64 - well, mostly, except leptonica and tesseract, which I also switched to stable git branch to successfully compile ffmpeg on MinGW64. But I think that's a different issue (or not?) ;-)

[LigH-de]

I would be a little bit sad if you disabled JPEGLI because it is just the "perceptual JPEG optimizer" I was looking for as substitute for XAT.com JPEG Optimizer. But of course I could download it from any other location, it was just convenient to have it built en passant as part of JPEGXL.

[L4cache]

I would be a little bit sad if you disabled JPEGLI because it is just the "perceptual JPEG optimizer" I was looking for as substitute for XAT.com JPEG Optimizer. But of course I could download it from any other location, it was just convenient to have it built en passant as part of JPEGXL.

It has migrated to it's own repo, so the "as part of JXL" one will be outdated (except security patches, maybe, like this commit)
https://github.com/google/jpegli

I'm not sure if they are going to eventually remove it from libjxl repo, leave it outdated forever, or "sync upstream" (who's upstream now?) someday, just speculating. Removing is the right choice in my opinion.