We don't provide a riscv64 wheel. This is failing on the freetype build. You can use system freetype instead of building freetype, which may get you further (https://matplotlib.org/stable/devel/dependencies.html#c-libraries). However, please take build problems to https://discourse.matplotlib.org as they are not really Matplotlib bugs per-se, Thanks

We don't provide a riscv64 wheel. This is failing on the freetype build. You can use system freetype instead of building freetype, which may get you further (https://matplotlib.org/stable/devel/dependencies.html#c-libraries). However, please take build problems to https://discourse.matplotlib.org as they are not really Matplotlib bugs per-se, Thanks

Thanks for your help,it's my problem.
Sorry
XD

We should consider adding riscv64 to

We should also consider doing something like

Fair - is there any reason to not always default to system freetype and only foist our freetype on developers who want image tests to pass?

fwiw this came in in #15476 in particular to help new contributors.

The core problem is that the Python native packaging / build tools can not express dependencies on non-python things it the meta-data. Building our own version of qhull and freetype by default makes it way easier to get set up for development with and escape hatch for downstream packagers (linux distros, conda, etc) that can express these dependencies in the package metadata to do so and not have us try to bring our own to the party.

For less common systems where our pinned version of freetype does not build (either because something is wrong with our method of calling configure + make or just that version of freetype does not support that architecture), then we default to system freetype to give the user a more useful error message ("can not find header") instead.

Another reason for this is that if a new person needs to add an image test odds are good that they will automatically have the right version of freetype!

I guess the question is what do we have more of - devs building matplotlib and running/submitting tests, or users trying to build their own wheels on systems that can't build freetype?

For less common systems where our pinned version of freetype does not build (either because something is wrong with our method of calling configure + make or just that version of freetype does not support that architecture), then we default to system freetype to give the user a more useful error message ("can not find header") instead.

I'm not following here - the OP's build failed trying to build 2.6.1. (configure: error: cannot guess build type; you must specify one). Were they supposed to fallback to the system freetype somehow? Or do you just mean we have to keep special casing all of these as they come up?

Instead of trying to special-case each and every platform where building freetype does not work, I wonder whether, in the case where system_freetype is false, we could first try to build our pinned freetype, and if that fails, catch that and (perhaps only if sys.platform not in ["linux", "win32", "darwin"] which are the (small, finite) list of known-good platforms) directly try to fallback to system_freetype? (Naturally the error messages may need to be updated in that case.)
(Perhaps also try that only if system_freeype = "false-with-fallback", a new default value (name up to bikeshedding).)

I'm using the matplotlib from the ubuntu.
It can works : )