[Bug]: Wheel's freetype binding can conflict with system library #32208

Bug summary

When using the matplotlib wheel from PyPI on Linux, the freetype symbols can conflict with the system freetype library. I think this might be a longstanding issue, but I can't find a previously opened issue about it and I think it only became salient when the bundled version of freetype started being updated (first in #29816).

Code for reproduction

To trigger the conflict, an older system freetype and recent version of matplotlib are needed.
One possible example of an older system is the UBI 9 container from Red Hat (registry.access.redhat.com/ubi9/ubi).
Here is a set of commands that triggers the conflict inside of that container:

dnf -y install pip freetype
python3 -m venv venv
./venv/bin/python -m pip install uv
./venv/bin/uv venv --python=3.13
./venv/bin/uv pip install matplotlib
./venv/bin/uv run python -c "import ctypes; ctypes.CDLL('/usr/lib64/libfreetype.so.6', mode=ctypes.RTLD_GLOBAL); \
import matplotlib; matplotlib.use('Agg'); import matplotlib.pyplot as p, io; \
f=p.subplots(figsize=(20,7))[0]; f.savefig(io.BytesIO(), format='png')"

Actual outcome

The end of the traceback from the example code is:

  File "/.venv/lib/python3.13/site-packages/matplotlib/backends/backend_agg.py", line 189, in _draw_text_glyphs_and_boxes
    bitmap = font._render_glyph(
        glyph_index, load_flags,
        RenderMode.NORMAL if gc.get_antialiased() else RenderMode.MONO)
RuntimeError: FT_Render_Glyph (ft2font_wrapper.cpp line 1943) failed with error 0x62: raster overflow

Expected outcome

No error from example code

Additional information

Adding import matplotlib.ft2font to the front of the Python code avoids the error because matplotlib binds to its freetype symbols instead of the system ones.

I open this issue partly just so somoene else searching for "raster overflow" or something similar gets a result explaining the problem. Perhaps it is possible to build the wheel so that matplotlib always binds to the bundled freetype symbols rather than possibly to the system versions? I don't know all the subtleties involved with binding to C library symbols so I don't suggest a solution strongly.

The ctypes.CDLL() call in the example code is a simplification of the original code that triggered this error which was using ROOT, in particular a system installation of ROOT and calling from ROOT import TCanvas (which loads the system freetype) before importing matplotlib.

Operating system

Linux (ubi 9 in the example)

Matplotlib Version

3.11.1

Matplotlib Backend

No response

Python version

3.13.15

Jupyter version

No response

Installation

uv