Re: LLVM 22 breaking some builds
On Mon, Mar 16, 2026 at 9:25 AM Tulio Magno Quites Machado Filho wrote: > > Michael J Gruber writes: > > > If it's rather something to be installed on top and used on a case by > > case basis, then a package specific path seems appropriate. Users > > would need to set their PYTHONPATH to prefer those specific paths, and > > probably adjust other env variables or build scripts so that a > > versioned clang is used instead of the unversioned one. > > Thanks for these suggestions. > In order to keep this new sub-package be available to developers too, > e.g. a mupdf developer working on both LLVM 21 and 22, I decided to > propose a solution based on this. > > llvm changes are being reviewed here: > https://src.fedoraproject.org/rpms/llvm/pull-request/572 > > I proposed the following changes to mupdf: > https://src.fedoraproject.org/rpms/mupdf/pull-request/9 > > I created the following Copr repository in order to test these changes: > https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/test-python-clang-compat/ > > I do have some questions on how to proceed with this on Fedora 44 in > case this proposed change is approved, though. > If we were in the beginning of the development cycle, I would definitely > list this change in the LLVM 22 Fedora change. That isn't the case, > though. > The change is just creating a sub-package in the compat package (llvm21) > that is already available in the main package (llvm-22). > With that said, I believe it's a safe change to be applied at this time. > > Would this change require its own Fedora Change? > Or is it OK to just update the contingency section at > https://fedoraproject.org/wiki/Changes/LLVM-22 ? > Mutually conflicting python-clang implementations are possible as long as they share a Provides+Conflicts stanza for a virtual name: e.g. Provides: pypi(clang) Conflicts: pypi(clang) It doesn't have to be anything complex or special, just something that literally does not exist (or cannot exist) as a package in Fedora. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Re: LLVM 22 breaking some builds
On Tue, Mar 10, 2026 at 11:32 AM Michael J Gruber
wrote:
> Am Di., 10. März 2026 um 10:43 Uhr schrieb Nikita Popov >:
> >
> >
> > On Mon, Mar 9, 2026 at 1:39 PM Michael J Gruber
> wrote:
> >>
> >> Hi there
> >>
> >> Apparently, LLVM changed something in the python API even though their
> >> release notes seem to claim otherwise. Here's a failed scratch build
> >> of a rawhide commit which worked before LLVM 22 landed
> >>
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=143160960
> >>
> >> Builds against other Fedoras work (until LLVM 22 lands there).
> >>
> >> This is unfortunate at this point in the release cycle. It's made
> >> worse by the fact that we do not ship python-clang compat packages. Is
> >> there a particular reason why not?
> >
> >
> > I believe the reason we don't ship python-clang in compat packages is
> that we don't know how to do that correctly. Normally, all the compat
> packages are shipped in /usr/lib64/llvmNN, so that would be something like
> /usr/lib64/llvmNN/lib/python3.14/site-packages/clang for python-clang. But
> I assume that wouldn't actually work because that's not the location where
> Python packages are expected to be located?
> >
> > I tried to look at what some compat packages from the Python ecosystem
> do. Looking at a package like python3-sqlalchemy1.4 it seems to just ship
> the files in the same location as the normal package and conflicts with it.
> This seems very fishy to me, and not really viable for us (as we'd have to
> conflict across all present and future compat packages).
> >
>
> First of all, those breakages should be caught before merging LLVM 22
> between two freezes. Everything else is work-arounds. Indeed, if
> there's clang21 but no python3-clang21 then testing packages which
> build require python-clang is much more important than testing those
> which BR clang.
>
LLVM updates generally rely on packages that are not compatible with the
latest version to switch to the compat packages instead. The fact that this
does not work for packages with python-clang BuildRequires wasn't on our
radar -- I think this just never came up in the past. Probably a
combination of few packages using python-clang, and those bindings being
relatively stable.
Ideally we'll address this by shipping an additional compat package, but
testing these python-clang BR packages in advance would be a fallback if
that's not possible.
> As for the path: It depends on the goal - (when) does it make sense to
> have different LLVM versions installed in parallel? If the answer is
> "no/never" (which is the answer from a build requires perspective),
> then the standard path and conflicts are appropriate.
>
> If it's rather something to be installed on top and used on a case by
> case basis, then a package specific path seems appropriate. Users
> would need to set their PYTHONPATH to prefer those specific paths, and
> probably adjust other env variables or build scripts so that a
> versioned clang is used instead of the unversioned one.
>
> One could also rename the python package (module) itself and put it in
> the standard path, but this would require adjusting a lot of import
> statements (import foo21 as foo and such).
>
> In summary, I'd rather know what changed and how to fix it ;-)
I took a quick look at this, the key change is the second bullet point in
https://releases.llvm.org/22.1.0/tools/clang/docs/ReleaseNotes.html#clang-python-bindings-potentially-breaking-changes,
the removal of elaborated types. The mupdf wrap script uses ELABORATED in
some places, but there's also some other consequences as a result of that.
In particular, some places that use get_declaration() now get a forward
declaration, rather than the definition they're looking for. The following
patch fixes the *first* error that shows up, but it's not the only one.
diff --git a/scripts/wrap/parse.py b/scripts/wrap/parse.py
index c3bd1278c..f0fe0c5f5 100644
--- a/scripts/wrap/parse.py
+++ b/scripts/wrap/parse.py
@@ -251,8 +251,8 @@ def has_refs( tu, type_):
if keep_fn_cursor:
if verbose:
jlib.log( 'There is a keep() fn for this type so
it uses reference counting: {keep_name=}')
-base_type_cursor = get_base_type(
type_).get_declaration()
-if base_type_cursor.is_definition():
+base_type_cursor = get_base_type(
type_).get_declaration().get_definition()
+if base_type_cursor is not None:
if verbose:
jlib.log( 'Type definition is available so we
look for .refs member: {key=} {type_.spelling=}
{fileline(base_type_cursor)=}')
if verbose:
@@ -289,7 +289,7 @@ def has_refs( tu, type_):
' declaration, so have to hard-code
the size and offset'
' of the refs member.'
)
-
Re: LLVM 22 breaking some builds
Am Di., 10. März 2026 um 10:43 Uhr schrieb Nikita Popov : > > > On Mon, Mar 9, 2026 at 1:39 PM Michael J Gruber > wrote: >> >> Hi there >> >> Apparently, LLVM changed something in the python API even though their >> release notes seem to claim otherwise. Here's a failed scratch build >> of a rawhide commit which worked before LLVM 22 landed >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=143160960 >> >> Builds against other Fedoras work (until LLVM 22 lands there). >> >> This is unfortunate at this point in the release cycle. It's made >> worse by the fact that we do not ship python-clang compat packages. Is >> there a particular reason why not? > > > I believe the reason we don't ship python-clang in compat packages is that we > don't know how to do that correctly. Normally, all the compat packages are > shipped in /usr/lib64/llvmNN, so that would be something like > /usr/lib64/llvmNN/lib/python3.14/site-packages/clang for python-clang. But I > assume that wouldn't actually work because that's not the location where > Python packages are expected to be located? > > I tried to look at what some compat packages from the Python ecosystem do. > Looking at a package like python3-sqlalchemy1.4 it seems to just ship the > files in the same location as the normal package and conflicts with it. This > seems very fishy to me, and not really viable for us (as we'd have to > conflict across all present and future compat packages). > First of all, those breakages should be caught before merging LLVM 22 between two freezes. Everything else is work-arounds. Indeed, if there's clang21 but no python3-clang21 then testing packages which build require python-clang is much more important than testing those which BR clang. As for the path: It depends on the goal - (when) does it make sense to have different LLVM versions installed in parallel? If the answer is "no/never" (which is the answer from a build requires perspective), then the standard path and conflicts are appropriate. If it's rather something to be installed on top and used on a case by case basis, then a package specific path seems appropriate. Users would need to set their PYTHONPATH to prefer those specific paths, and probably adjust other env variables or build scripts so that a versioned clang is used instead of the unversioned one. One could also rename the python package (module) itself and put it in the standard path, but this would require adjusting a lot of import statements (import foo21 as foo and such). In summary, I'd rather know what changed and how to fix it ;-) Michael -- ___ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Re: LLVM 22 breaking some builds
On Mon, Mar 9, 2026 at 1:39 PM Michael J Gruber wrote: > Hi there > > Apparently, LLVM changed something in the python API even though their > release notes seem to claim otherwise. Here's a failed scratch build > of a rawhide commit which worked before LLVM 22 landed > > https://koji.fedoraproject.org/koji/taskinfo?taskID=143160960 > > Builds against other Fedoras work (until LLVM 22 lands there). > > This is unfortunate at this point in the release cycle. It's made > worse by the fact that we do not ship python-clang compat packages. Is > there a particular reason why not? > I believe the reason we don't ship python-clang in compat packages is that we don't know how to do that correctly. Normally, all the compat packages are shipped in /usr/lib64/llvmNN, so that would be something like /usr/lib64/llvmNN/lib/python3.14/site-packages/clang for python-clang. But I assume that wouldn't actually work because that's not the location where Python packages are expected to be located? I tried to look at what some compat packages from the Python ecosystem do. Looking at a package like python3-sqlalchemy1.4 it seems to just ship the files in the same location as the normal package and conflicts with it. This seems very fishy to me, and not really viable for us (as we'd have to conflict across all present and future compat packages). Regards, Nikita -- ___ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
