Created attachment 25437 [details] clang17 In Fedora's development branch (rawhide), we recently switch clang/llvm from 17 to 18.0.1-rc4. This is when building mupdf stopped to work, both with mupdf from current master as well as mupdf 1.23.10 (with cherry-picks from master). The main issue seems to be that mupdfwrap fails to create most of the wrappers. You can see this from the build logs in our test platform (f39, f40 works, rawhide fails): https://copr.fedorainfracloud.org/coprs/mjg/mupdf-git/build/7112494/ As a quick example, I'll attach platform/c++/implementation/classes2.cpp as generated by clang17 (f39) and clang18 (rawhide) in a local mock (chroot) build of mupdf 1.23.10 (with ...).
Created attachment 25438 [details] clang18
As an additional point of input: It is only the step ./scripts/mupdfwrap.py -d build/shared-debug -b 0 which requires clang 17 - I can continue the rest of the build (-b 1) without clang 17 (and clang 18 instead). Also, I've trimmed this down to the extent that I can use clang 17 with the clang 18/llvm 18 header files etc. That is, the difference comes from the difference in parsers only.
It looks like the failure was caused by: github.com/llvm/llvm-project/commit/7091ca1ae3a87479b6febdf1c3a324d707c633d9
Created attachment 25479 [details] Build fix This fixes the build with llvm18, but it needs to have some version checks added, because it will break the build with llvm < 18.
(In reply to tstellar from comment #4) > Created attachment 25479 [details] > Build fix > > This fixes the build with llvm18, but it needs to have some version checks > added, because it will break the build with llvm < 18. Thanks for looking into and suggesting a fix for this problem. I did install clang-18 and build the core mupdf library successfully, but had trouble testing the bindings. I will ask my colleague who wrote the script used for the bindings to look into this. We may possibly want both for both 1.24.0 and 1.23.x.
I have a fix that makes things work with clang 18. [NB There's an unrelated problem with pypi.org's wheel for libclang-macos-arm64.] Will hopefully review/push it soon.
Created attachment 25491 [details] Build fix (works with both clang 18 and clang < 18) It appears we can simply use both cursor types and this works at least with clang 17 and clang 18 in my testing. (I slightly modified Tom's patch.)
I've pushed my fix (similar to M.J.G.'s fix, but with extra workaround for macos-arm64) to branch master.
Fixed in commit 75e14b6ae006367b3ece7b5c8fc21e64bf22cb82 Author: Julian Smith <julian.smith@artifex.com> Date: Mon Mar 18 14:10:34 2024 +0000 Fix build of C++ bindings with new libclang-18. scripts/wrap/parse.py:get_children(): With libclang 18, we need to look inside `extern "C" {...}` for top-level items. scripts/wrap/__main__.py: Fix assert when using -x64 or -py builddir suffix. Use setup.py:get_requires_for_build_wheel() to get list of required packages for venv. pyproject.toml setup.py: Specify required packages with setup.py:get_requires_for_build_wheel() instead of pyproject.toml; we need programmatic control because latest libclang 18.1.1 does not work with macos/arm64.