Compatibility problem with free-threading Python 3.14t on Windows

[hesl-seu]

Description

I'm trying to install osqp 1.0.5 on free-threading Python 3.14t. As no binaries provided in pypi, it is automatically installed from the source.
However, there will be a link error when building:

LINK : fatal error LNK1104: cannot open file 'python314.lib'

Possible solution

I have checked that the library file is called "python3.14t.lib" on Windows for 3.14t. Probably, something needs to be fixed in a CMake file somewhere.

[vineetbansal]

@hesl-seu - thanks. Note that we're experiencing some solver issues (converging to a different result than in version 3.12 and below) due to the underlying code being not thread safe, which is why we haven't released wheels for any of the free-threaded python versions.

So even if you're able to get it to compile, osqp will likely not work as intended. My suggestion would be to use a non free-threaded interpreter if possible.

There's no ETA on this but we hope to fix the error soon.

[imciner2]

While we won't officially support free-threading until we sort out a few internal parts, I think this problem might just be a problem with having too old a CMake version when you try to build the free-threading version.

It looks like free-threading was only added to CMake last year (https://gitlab.kitware.com/cmake/cmake/-/issues/26016, and the PR implementing it is https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9578). According to that, it looks to be in CMake 3.30. So to build wheels for free-threading, we will need to have a CMake version greater than that (so 3.30.x or 4.x). Although apparently 3.13 free-threading had a bug with the headers, and CMake only added a workaround for it in 3.30.3 (https://gitlab.kitware.com/cmake/cmake/-/issues/26016#note_1539050).

I wonder, is it worth trying to get 3.13 free-threading wheels, or should we only enable this for 3.14?

[hesl-seu]

Thanks for your attention. Actually I'm using cmake 4.x with Visual Studio on Windows. It seems to raise errors that others never meet. I'll check my environment to see if the configurations are really ok.

[travis-leith]

@hesl-seu - thanks. Note that we're experiencing some solver issues (converging to a different result than in version 3.12 and below) due to the underlying code being not thread safe, which is why we haven't released wheels for any of the free-threaded python versions.

So even if you're able to get it to compile, osqp will likely not work as intended. My suggestion would be to use a non free-threaded interpreter if possible.

There's no ETA on this but we hope to fix the error soon.

Just to be clear and explicit about this: if I use python 3.14 with default settings (which still uses the GIL because free threading is opt in) then osqp is expected to work correctly?

[hesl-seu]

@travis-leith In my situation, osqp could be installed properly from the source in noraml Python 3.14. But I'm not directly using osqp. Instead, I'm using cvxpy (which depends on osqp) to solve simple quadratic optimization problem. So far I have not met any problems.

[imciner2]

Yes, if you use OSQP with a non-free-threading Python then everything will work correctly and it will build. The issue is just with the free-threading version.

I did some more digging, and it looks like we are also being limited by the PyBind11 support for freethreading. There are bugs such as pybind/pybind11#5884 that seem to suggest PyBind11 isn't fully supporting building against the free-threading libraries yet.