Do we have a setup to test this on?

It seems a bit weird to drop into a single test invocation, but we could maybe do so. Basically runningCFLAGS=-fno-lto pip install -e .

we could run just of the existing builds with that flag? The issues reports that it builds clean but then fails to import so we need to run something.

That would also help us catch any (hopefully very edge) cases where LTO changes behavior on us?

So I tested by justaddingCFLAGS everywhere and strangely, it only fails on the subprocess tests. I can reproduce locally, so will figure that out tomorrow.

Ah, I think I've figured it out now; Python compiles the files withgcc (usingCFLAGS) and then compiles the final library withg++ (usingCXXFLAGS). This is a bit weird to me since they have.cpp extensions, but I guess it works. However, that means that the second call does not get a-fno-lto flag (and neither does it see our lto flags since this PR would disable them) and by default it at least doessome LTO/visibility stuff.

So I'm going to say that this is not our bug to fix. If you want to set*FLAGS, you need to setall of them consistently.

I will setup the test to do the same.

Nope, sorry, I got that all wrong. The problem is thattkagg.cpp includespy_converters.h due to#12569, and#19094 removes the NumPy array reference to silence a warning, but means that the symbol does not exist for the stuff inpy_converters.h.

With LTO, the NumPy-referencing converters are stripped due to being unused, and apparently, with no LTO option specified, that also happens. But with-fno-lto, no unused converters are stripped and this results in a missing symbol.

This now fixes the build with LTO disabled in the environment, by splitting the converters into two separate files so that the tkagg backend does not need to use NumPy. It also adds theCFLAGS in one test environment.

(I don't mind reverting#19094 if that makes things simpler -- it's only a compile-time warning anyways...)

Pre-release failures are tracked in#19352.

Seems to be the other windows build that's failing?

@anntzer can you review and merge? I don't quite understand the file split, nor do I really track the compile time flag subtleties. Whereas this change seems to have been necessitated by a change you recently made.

I honestly don't really follow what's happening, and as stated above, I'd rather just revert#19094 if that's sufficient, as#19094 really just suppressed a harmless build-time warning.

Or the following should work too? (possibly still with the setup.py additional checks)

diff --git a/src/_tkagg.cpp b/src/_tkagg.cppindex 3e5793f03..60dc53d6e 100644--- a/src/_tkagg.cpp+++ b/src/_tkagg.cpp@@ -33,14 +33,10 @@ #define dlsym GetProcAddress #else #include <dlfcn.h>-// Suppress -Wunused-function on POSIX, but not on Windows where that would-// lead to PY_ARRAY_UNIQUE_SYMBOL being an unresolved external.-#define NO_IMPORT_ARRAY #endif  // Include our own excerpts from the Tcl / Tk headers #include "_tkmini.h"-#include "py_converters.h"  // Global vars for Tk functions.  We load these symbols from the tkinter // extension module or loaded Tk libraries at run-time.@@ -49,19 +45,23 @@ static Tk_PhotoPutBlock_NoComposite_t TK_PHOTO_PUT_BLOCK_NO_COMPOSITE;  static PyObject *mpl_tk_blit(PyObject *self, PyObject *args) {+    PyObject *py_interp;     Tcl_Interp *interp;     char const *photo_name;     int height, width;+    PyObject *py_data_ptr;     unsigned char *data_ptr;     int o0, o1, o2, o3;     int x1, x2, y1, y2;     Tk_PhotoHandle photo;     Tk_PhotoImageBlock block;-    if (!PyArg_ParseTuple(args, "O&s(iiO&)(iiii)(iiii):blit",-                          convert_voidptr, &interp, &photo_name,-                          &height, &width, convert_voidptr, &data_ptr,+    if (!PyArg_ParseTuple(args, "Os(iiO)(iiii)(iiii):blit",+                          &py_interp, &photo_name,+                          &height, &width, &py_data_ptr,                           &o0, &o1, &o2, &o3,-                          &x1, &x2, &y1, &y2)) {+                          &x1, &x2, &y1, &y2)+        || !(interp = (Tcl_Interp *)PyLong_AsVoidPtr(py_interp))+        || !(data_ptr = (unsigned char *)PyLong_AsVoidPtr(py_data_ptr))) {         goto exit;     }     if (!(photo = TK_FIND_PHOTO(interp, photo_name))) {diff --git a/src/py_converters.cpp b/src/py_converters.cppindex ace8332dd..a4c0b1909 100644--- a/src/py_converters.cpp+++ b/src/py_converters.cpp@@ -94,13 +94,6 @@ int convert_from_attr(PyObject *obj, const char *name, converter func, void *p)     return 1; }-int convert_voidptr(PyObject *obj, void *p)-{-    void **val = (void **)p;-    *val = PyLong_AsVoidPtr(obj);-    return *val != NULL ? 1 : !PyErr_Occurred();-}- int convert_double(PyObject *obj, void *p) {     double *val = (double *)p;diff --git a/src/py_converters.h b/src/py_converters.hindex 33af43a47..2c19acdaa 100644--- a/src/py_converters.h+++ b/src/py_converters.h@@ -22,7 +22,6 @@ typedef int (*converter)(PyObject *, void *); int convert_from_attr(PyObject *obj, const char *name, converter func, void *p); int convert_from_method(PyObject *obj, const char *name, converter func, void *p);-int convert_voidptr(PyObject *obj, void *p); int convert_double(PyObject *obj, void *p); int convert_bool(PyObject *obj, void *p); int convert_cap(PyObject *capobj, void *capp);

Both#19094 and reverting it are just workarounds for the real problem, which is that_tkagg.so is compiling in NumPy functions and thus should be linked with NumPy, whenit doesn't need it. That why this splits converters between simple Python ones and ones that really need NumPy.

If you prefer to inlineconvert_voidptr, that does work too; it's only used in tkagg.

If you prefer to inline convert_voidptr, that does work too; it's only used in tkagg.

Let's go for the simpler(?) solution then?

CI failures are known issues.