Bug 2492227

Indeed, it sounds like materialx broke ABI without bumping the SONAME version, which is an error. I agree that the best thing we can do is to just rebuild usd and move on. I expect that Fedora 43 is suffering from the same problem, and that rebuilding usd and moving on is the best thing we can do at the moment. It’s possible that Blender itself might need a rebuild, too. The materialx package should be updated more carefully from now on, given that we have evidence upstream isn’t taking care with ABI/SONAME versioning.

Created attachment 2146518 [details]
ABI diff

$ abipkgdiff ./materialx-1.39.4-6.fc44.x86_64.rpm ./materialx-1.39.5-1.fc44.x86_64.rpm

FEDORA-2026-19ee9e9792 (usd-26.03-4.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-19ee9e9792

I manually pulled and installed usd and usd-libs version 26.03-4.fc44 from Koji to test. After updating, Blender fails to launch with a symbol lookup error:

blender: symbol lookup error: blender: undefined symbol: _ZTVN17MaterialX_v1_39_46OutputE

This seems to confirm that suspicion, meaning Blender will likely need a rebuild against the updated MaterialX 1.39.5 / USD stack to resolve this.

Luya, it looks like there are some commits that have been merged into Blender but not built yet. Is that branch in a state that is ready to ship?

Yes, it is ready

FEDORA-2026-5f0e71928f (blender-5.1.2-3.fc43 and usd-25.08-21.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-5f0e71928f

Waiting for https://bodhi.fedoraproject.org/updates/FEDORA-2026-19ee9e9792 to be “unlocked” after F44 composes failed today, so I can unpush it and create a new update that includes Blender.

FEDORA-2026-19ee9e9792 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-19ee9e9792`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-19ee9e9792

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-5f0e71928f has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-5f0e71928f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-5f0e71928f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-872aaa784d (blender-5.1.2-5.fc44 and usd-26.03-4.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-872aaa784d

FEDORA-2026-872aaa784d has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-872aaa784d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-872aaa784d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

When downgrading MaterialX blender works but starts in fallbackmode because an OpenColorIO version mismach.
The.ocio config is version 2.5, the version of the OpenColorIO library (2.4.2) is not able to load that config version.

That is correct. Downgrading MaterialX is only a temporary workaround for the USD crash, but it exposes the underlying OpenColorIO/OpenImageIO mismatch on Fedora 44 (where the packaged OCIO is 2.4.2, but Blender looks for 2.5+ configs). 
The good news: Once the new Blender package rebuild (which fixes the MaterialX ABI breakage) hits stable, you can safely upgrade MaterialX again. 
But when running the rebuilt Blender package, it will still show the OCIO warning in the terminal and switch to fallback mode, but the application itself is fully functional and won't crash. 

@Ben Beasley: Should I open a separate Bugzilla ticket for the OpenColorIO 2.4.2 vs 2.5 config mismatch to track that cleanly, or do you prefer to handle it as part of a future system-wide OCIO package update?

(In reply to Mia from comment #14)
> @Ben Beasley: Should I open a separate Bugzilla ticket for the OpenColorIO
> 2.4.2 vs 2.5 config mismatch to track that cleanly, or do you prefer to
> handle it as part of a future system-wide OCIO package update?

Hmm, you may as well open a new issue, I suppose. I help out quite a lot with usd, but I don’t really actively or regularly co-maintain Blender in practice beyond the occasional rebuilds and rare self-contained bug fixes. I think it will need to be up to Luya to figure out what to do about the OCIO mismatch.

(I would note that updating OpenColorIO from 2.4 to 2.5 is an ABI-breaking change. In F44, it would require an Updates Policy exception from FESCo and coordination with / rebuilds of several other packages.)

(In reply to Ben Beasley from comment #15)
> (In reply to Mia from comment #14)
> > @Ben Beasley: Should I open a separate Bugzilla ticket for the OpenColorIO
> > 2.4.2 vs 2.5 config mismatch to track that cleanly, or do you prefer to
> > handle it as part of a future system-wide OCIO package update?
> 
> Hmm, you may as well open a new issue, I suppose. I help out quite a lot
> with usd, but I don’t really actively or regularly co-maintain Blender in
> practice beyond the occasional rebuilds and rare self-contained bug fixes. I
> think it will need to be up to Luya to figure out what to do about the OCIO
> mismatch.
> 
> (I would note that updating OpenColorIO from 2.4 to 2.5 is an ABI-breaking
> change. In F44, it would require an Updates Policy exception from FESCo and
> coordination with / rebuilds of several other packages.)

Thanks for the insights, Ben! Given that updating OpenColorIO to 2.5 would trigger a major ABI breakage and require a FESCo exception for a stable release, that sounds like an immense amount of work. 
Since Blender runs perfectly fine in its fallback mode for everyday modeling and rendering—and the 2.5 config features are mostly critical for highly specialized studio pipelines (where Fedora's market share might not justify the massive rebuild effort anyway)—it's probably not worth forcing a global library upgrade right now. 
I think I'll hold off on opening a new ticket for now, unless the fallback mode causes actual workflow breakages for users downstream. Thanks again for the swift MaterialX rebuild!

FEDORA-2026-872aaa784d (blender-5.1.2-5.fc44 and usd-26.03-4.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2026-5f0e71928f (blender-5.1.2-3.fc43 and usd-25.08-21.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.