Cannot install python-pkcs11 using python 3.12

I tried to install python-pkcs11 using pip 23.2.1 and python 3.12 Here is what I keep encountering, Need help!

Summary: pkcs11/_pkcs11.c(46416): warning C4013: 'PyUnicode_AsUnicode' undefined; assuming extern returning int pkcs11/_pkcs11.c(46416): warning C4047: '=': 'LPCWSTR' differs in levels of indirection from 'int' pkcs11/_pkcs11.c(46416): warning C4013: 'PyUnicode_AsUnicode' undefined; assuming extern returning int

I have tried getting the latest version of Cython - 3.0.4 which was released 10/17/23 and still have no luck.

Detailed log: python -m pip install --use-pep517 python-pkcs11 --user Collecting python-pkcs11 Using cached python-pkcs11-0.7.0.tar.gz (106 kB) Installing build dependencies ... done Getting requirements to build wheel ... done Installing backend dependencies ... done Preparing metadata (pyproject.toml) ... done Requirement already satisfied: asn1crypto in e:\workdir\saiga\tools\python-win64-3.12.0\lib\site-packages (from python-pkcs11) (1.5.1) Requirement already satisfied: cached-property in e:\workdir\saiga\tools\python-win64-3.12.0\lib\site-packages (from python-pkcs11) (1.5.2) Building wheels for collected packages: python-pkcs11 Building wheel for python-pkcs11 (pyproject.toml) ... error error: subprocess-exited-with-error

× Building wheel for python-pkcs11 (pyproject.toml) did not run successfully. │ exit code: 1 ╰─> [431 lines of output] WARNING setuptools_scm.pyproject_reading toml section missing 'pyproject.toml does not contain a tool.setuptools_scm section' running bdist_wheel running build running build_py creating build creating build\lib.win-amd64-cpython-312 creating build\lib.win-amd64-cpython-312\pkcs11 copying pkcs11\constants.py -> build\lib.win-amd64-cpython-312\pkcs11 copying pkcs11\defaults.py -> build\lib.win-amd64-cpython-312\pkcs11 copying pkcs11\exceptions.py -> build\lib.win-amd64-cpython-312\pkcs11 copying pkcs11\mechanisms.py -> build\lib.win-amd64-cpython-312\pkcs11 copying pkcs11\types.py -> build\lib.win-amd64-cpython-312\pkcs11 copying pkcs11__init.py -> build\lib.win-amd64-cpython-312\pkcs11 creating build\lib.win-amd64-cpython-312\pkcs11\util copying pkcs11\util\dh.py -> build\lib.win-amd64-cpython-312\pkcs11\util copying pkcs11\util\dsa.py -> build\lib.win-amd64-cpython-312\pkcs11\util copying pkcs11\util\ec.py -> build\lib.win-amd64-cpython-312\pkcs11\util copying pkcs11\util\rsa.py -> build\lib.win-amd64-cpython-312\pkcs11\util copying pkcs11\util\x509.py -> build\lib.win-amd64-cpython-312\pkcs11\util copying pkcs11\util\init__.py -> build\lib.win-amd64-cpython-312\pkcs11\util running egg_info writing python_pkcs11.egg-info\PKG-INFO writing dependency_links to python_pkcs11.egg-info\dependency_links.txt writing requirements to python_pkcs11.egg-info\requires.txt writing top-level names to python_pkcs11.egg-info\top_level.txt ERROR setuptools_scm._file_finders.git listing git files failed - pretending there aren't any reading manifest file 'python_pkcs11.egg-info\SOURCES.txt' writing manifest file 'python_pkcs11.egg-info\SOURCES.txt' copying pkcs11_errors.pyx -> build\lib.win-amd64-cpython-312\pkcs11 copying pkcs11_mswin.pxd -> build\lib.win-amd64-cpython-312\pkcs11 copying pkcs11_pkcs11.pyx -> build\lib.win-amd64-cpython-312\pkcs11 copying pkcs11_pkcs11_defn.pxd -> build\lib.win-amd64-cpython-312\pkcs11 copying pkcs11_utils.pyx -> build\lib.win-amd64-cpython-312\pkcs11 running build_ext warning: pkcs11_pkcs11.pyx:17:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310 warning: pkcs11_errors.pyx:85:44: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython. warning: pkcs11_pkcs11.pyx:1366:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions o r C macros instead. See https://github.com/cython/cython/issues/4310 warning: pkcs11_pkcs11.pyx:1390:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions o r C macros instead. See https://github.com/cython/cython/issues/4310 warning: pkcs11_pkcs11.pyx:1421:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions o r C macros instead. See https://github.com/cython/cython/issues/4310 performance hint: pkcs11_errors.pyx:85:6: Exception check on 'assertRV' will always require the GIL to be acquired. Possible solutions:

Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:196:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:211:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:219:70: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:219:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:230:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:268:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:274:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:282:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:303:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:316:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:336:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:363:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:366:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:380:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:427:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:488:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:566:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:582:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:590:63: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:590:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:606:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:609:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:616:51: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:615:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:633:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:640:32: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:646:32: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:651:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:656:64: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:656:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:720:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:731:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:747:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:759:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:769:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:855:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:892:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:896:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:903:56: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:902:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:935:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:947:74: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:946:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:957:67: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:957:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:983:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:987:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:994:55: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:993:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1026:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1038:74: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1037:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1048:67: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1048:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1074:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1077:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1084:52: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1083:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1105:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1115:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1120:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1125:65: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1125:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1150:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1152:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1172:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1182:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1186:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1210:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1217:59: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1216:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1276:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1338:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1409:38: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you cont rol the definition and you're sure you don't want the function to raise exceptions. performance hint: pkcs11_pkcs11.pyx:1409:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1432:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1439:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1470:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1478:64: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1478:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1487:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1556:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1557:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1562:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. Compiling pkcs11/_pkcs11.pyx because it changed. [1/1] Cythonizing pkcs11/_pkcs11.pyx building 'pkcs11._pkcs11' extension creating build\temp.win-amd64-cpython-312 creating build\temp.win-amd64-cpython-312\Release creating build\temp.win-amd64-cpython-312\Release\pkcs11 "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.37.32822\bin\HostX86\x64\cl.exe" /c /nologo /O2 /W3 /GL /DNDEBUG /MD -I E:\workdir\saiga\tools\python-win64-3.12.0\include -IE:\workdir\saiga\tools\python-win64-3.12.0\Include "-IC:\Program Files (x86)\Microsoft Visual Studio\2022 \BuildTools\VC\Tools\MSVC\14.37.32822\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\VS\include" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\um" "-IC:\Program Files (x86)\Windows Kits\1 0\include\10.0.22621.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10 .0.22621.0\cppwinrt" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" /Tcpkcs11/pkcs11.c /Fobuild\temp.win-amd64-cpython-312\Release\pkcs11/ pkcs11.obj _pkcs11.c pkcs11/_pkcs11.c(20579): warning C4013: 'PyUnicode_FromUnicode' undefined; assuming extern returning int pkcs11/_pkcs11.c(20579): warning C4047: '=': 'PyObject *' differs in levels of indirection from 'int' pkcs11/_pkcs11.c(25652): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(32065): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(32674): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(33549): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(37619): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(38606): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(39331): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(40318): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(41042): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(41902): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(42574): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(42594): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(43126): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(43340): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(45092): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(46416): warning C4013: 'PyUnicode_AsUnicode' undefined; assuming extern returning int pkcs11/_pkcs11.c(46416): warning C4047: '=': 'LPCWSTR' differs in levels of indirection from 'int' pkcs11/_pkcs11.c(60954): warning C4244: '=': conversion from 'Py_ssize_t' to 'long', possible loss of data pkcs11/_pkcs11.c(61137): warning C4244: '=': conversion from 'Py_ssize_t' to 'long', possible loss of data Traceback (most recent call last): File "E:\workdir\saiga\tools\python-win64-3.12.0\Lib\site-packages\pip_vendor\pyproject_hooks_in_process_in_process.py", line 353, in
main() File "E:\workdir\saiga\tools\python-win64-3.12.0\Lib\site-packages\pip_vendor\pyproject_hooks_in_process_in_process.py", line 335, in main json_out['return_val'] = hook(hook_input['kwargs']) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "E:\workdir\saiga\tools\python-win64-3.12.0\Lib\site-packages\pip_vendor\pyproject_hooks_in_process_in_process.py", line 251, in build_wheel return _build_backend().build_wheel(wheel_directory, config_settings, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools\build_meta.py", line 434, in build_wheel return self._build_with_temp_dir( ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools\build_meta.py", line 419, in _build_with_temp_d ir self.run_setup() File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools\build_meta.py", line 507, in run_setup super(_BuildMetaLegacyBackend, self).run_setup(setup_script=setup_script) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools\build_meta.py", line 341, in run_setup exec(code, locals()) File "", line 30, in File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools__init__.py", line 103, in setup return distutils.core.setup(attrs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\core.py", line 185, in setup return run_commands(dist) ^^^^^^^^^^^^^^^^^^ File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\core.py", line 201, in run_commands dist.run_commands() File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\dist.py", line 969, in run_commands self.run_command(cmd) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools\dist.py", line 989, in run_command super().run_command(command) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\dist.py", line 988, in run_command cmd_obj.run() File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\wheel\bdist_wheel.py", line 364, in run self.run_command("build") File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\cmd.py", line 318, in run_command self.distribution.run_command(command) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools\dist.py", line 989, in run_command super().run_command(command) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\dist.py", line 988, in run_command cmd_obj.run() File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\command\build.py", line 131, in run self.run_command(cmd_name) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\cmd.py", line 318, in run_command self.distribution.run_command(command) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools\dist.py", line 989, in run_command super().run_command(command) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\dist.py", line 988, in run_command cmd_obj.run() File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools\command\build_ext.py", line 88, in run _build_ext.run(self) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\command\build_ext.py", line 345, in run self.build_extensions() File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\command\build_ext.py", line 467, in build_extensions self._build_extensions_serial() File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\command\build_ext.py", line 493, in _build_extensions_serial self.build_extension(ext) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools\command\build_ext.py", line 249, in build_exten sion _build_ext.build_extension(self, ext) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\normal\Lib\site-packages\Cython\Distutils\build_ext.py", line 135, in build_extensio n super(build_ext, self).build_extension(ext) File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\command\build_ext.py", line 575, in build_extension libraries=self.get_libraries(ext), ^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Users\abargale\AppData\Local\Temp\pip-build-env-orv4yjau\overlay\Lib\site-packages\setuptools_distutils\command\build_ext.py", line 788, in get_libraries return ext.libraries + py37compat.pythonlib()
```
  TypeError: can only concatenate tuple (not "list") to tuple
  [end of output]
```

I tried cloning the repo locally and trying to build - here is what I get again.

Summary: Creating library build\temp.win-amd64-cpython-312\Release\pkcs11_pkcs11.cp312-win_amd64.lib and object build\temp.win-amd64-cpython-312\Release\pkcs 11_pkcs11.cp312-win_amd64.exp _pkcs11.obj : error LNK2001: unresolved external symbol PyUnicode_AsUnicode _pkcs11.obj : error LNK2001: unresolved external symbol PyUnicode_FromUnicode build\lib.win-amd64-cpython-312\pkcs11_pkcs11.cp312-win_amd64.pyd : fatal error LNK1120: 2 unresolved externals error: command 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.37.32822\bin\HostX86\x64\link.exe' failed with exit code 1120

Detailed log:

python -m pip install --use-pep517 --no-clean E:\xx\xxx\python-pkcs11 --user Processing e:\xx\xxx\python-pkcs11 Installing build dependencies ... done Getting requirements to build wheel ... done Installing backend dependencies ... done Preparing metadata (pyproject.toml) ... done Requirement already satisfied: asn1crypto>=1.0.0 in e:\xx\xxx\xxxxx\python-win64-3.12.0\lib\site-packages (from python-pkcs11==0.7.1.dev40+gff20b84) (1 .5.1) Requirement already satisfied: cached-property in e:\xx\xxx\xxxxx\tools\python-win64-3.12.0\lib\site-packages (from python-pkcs11==0.7.1.dev40+gff20b84) (1.5 .2) Building wheels for collected packages: python-pkcs11 Building wheel for python-pkcs11 (pyproject.toml) ... error error: subprocess-exited-with-error

× Building wheel for python-pkcs11 (pyproject.toml) did not run successfully. │ exit code: 1 ╰─> [375 lines of output] WARNING setuptools_scm.pyproject_reading toml section missing 'pyproject.toml does not contain a tool.setuptools_scm section' running bdist_wheel running build running build_py running egg_info writing python_pkcs11.egg-info\PKG-INFO writing dependency_links to python_pkcs11.egg-info\dependency_links.txt writing requirements to python_pkcs11.egg-info\requires.txt writing top-level names to python_pkcs11.egg-info\top_level.txt WARNING setuptools_scm._file_finders.git toplevel mismatch computed e:\workdir\software\python-pkcs11 vs resolved E:\workdir\software\python-pkcs11 adding license file 'LICENSE' writing manifest file 'python_pkcs11.egg-info\SOURCES.txt' running build_ext warning: pkcs11_pkcs11.pyx:17:0: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions or C macros instead. See https://github.com/cython/cython/issues/4310 warning: pkcs11_errors.pyx:86:44: The keyword 'nogil' should appear at the end of the function signature line. Placing it before 'except' or 'noexcept' will be disallowed in a future version of Cython. warning: pkcs11_pkcs11.pyx:1443:4: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions o r C macros instead. See https://github.com/cython/cython/issues/4310 warning: pkcs11_pkcs11.pyx:1467:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions o r C macros instead. See https://github.com/cython/cython/issues/4310 warning: pkcs11_pkcs11.pyx:1498:8: The 'IF' statement is deprecated and will be removed in a future Cython version. Consider using runtime conditions o r C macros instead. See https://github.com/cython/cython/issues/4310 performance hint: pkcs11_errors.pyx:86:6: Exception check on 'assertRV' will always require the GIL to be acquired. Possible solutions:

Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:216:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:231:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:239:70: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:239:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:250:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:289:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:295:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:303:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:324:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:337:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:357:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:384:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:387:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:401:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:448:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:509:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:587:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:603:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:611:63: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:611:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:627:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:630:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:637:51: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:636:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:654:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:661:32: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:667:32: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:672:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:677:64: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:677:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:741:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:752:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:768:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:780:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:790:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:876:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:913:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:917:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:924:56: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:923:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:956:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:968:74: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:967:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:978:67: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:978:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1013:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1017:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1022:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1029:55: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1028:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1070:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1074:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1087:74: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1086:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1097:67: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1097:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1132:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1136:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1140:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1147:52: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1146:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1177:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1181:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1192:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1197:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1202:65: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1202:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1227:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1229:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1249:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1259:28: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1263:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1287:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1294:59: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1293:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1353:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1415:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1486:38: Exception check will always require the GIL to be acquired. Declare the function as 'noexcept' if you cont rol the definition and you're sure you don't want the function to raise exceptions. performance hint: pkcs11_pkcs11.pyx:1486:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1509:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1516:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1547:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. warning: pkcs11_pkcs11.pyx:1555:64: Use boundscheck(False) for faster access performance hint: pkcs11_pkcs11.pyx:1555:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1564:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1638:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1643:20: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1654:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1655:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. performance hint: pkcs11_pkcs11.pyx:1660:24: Exception check will always require the GIL to be acquired. Possible solutions:
Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
Use an 'int' return type on the function to allow an error code to be returned. Compiling pkcs11/_pkcs11.pyx because it changed. [1/1] Cythonizing pkcs11/_pkcs11.pyx building 'pkcs11._pkcs11' extension "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.37.32822\bin\HostX86\x64\cl.exe" /c /nologo /O2 /W3 /GL /DNDEBUG /MD -I E:\workdir\saiga\tools\python-win64-3.12.0\include -IE:\workdir\saiga\tools\python-win64-3.12.0\Include "-IC:\Program Files (x86)\Microsoft Visual Studio\2022 \BuildTools\VC\Tools\MSVC\14.37.32822\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\VS\include" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\um" "-IC:\Program Files (x86)\Windows Kits\1 0\include\10.0.22621.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10 .0.22621.0\cppwinrt" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" /Tcpkcs11/pkcs11.c /Fobuild\temp.win-amd64-cpython-312\Release\pkcs11/ pkcs11.obj _pkcs11.c pkcs11/_pkcs11.c(21005): warning C4013: 'PyUnicode_FromUnicode' undefined; assuming extern returning int pkcs11/_pkcs11.c(21005): warning C4047: '=': 'PyObject *' differs in levels of indirection from 'int' pkcs11/_pkcs11.c(24021): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(24164): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(26410): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(32821): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(33430): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(34305): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(38375): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(39362): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(40106): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(40170): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(41074): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(41334): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(42077): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(42141): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(42917): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(43177): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(43850): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(43870): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(44402): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(44616): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(46368): warning C4244: '=': conversion from 'Py_ssize_t' to 'CK_ULONG', possible loss of data pkcs11/_pkcs11.c(47692): warning C4013: 'PyUnicode_AsUnicode' undefined; assuming extern returning int pkcs11/_pkcs11.c(47692): warning C4047: '=': 'LPCWSTR' differs in levels of indirection from 'int' pkcs11/_pkcs11.c(62687): warning C4244: '=': conversion from 'Py_ssize_t' to 'long', possible loss of data pkcs11/_pkcs11.c(62974): warning C4244: '=': conversion from 'Py_ssize_t' to 'long', possible loss of data "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.37.32822\bin\HostX86\x64\link.exe" /nologo /INCREMENTAL:NO /LTCG /DLL / MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:E:\workdir\saiga\tools\python-win64-3.12.0\libs /LIBPATH:E:\workdir\saiga\tools\python-win64-3.12.0 /LIBPATH:E:\w orkdir\saiga\tools\python-win64-3.12.0\PCbuild\amd64 "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.37.32822\lib\x6 4" "/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.22621.0\ucrt\x64" "/LIBPAT H:C:\Program Files (x86)\Windows Kits\10\lib\10.0.22621.0\um\x64" user32.lib /EXPORT:PyInit__pkcs11 build\temp.win-amd64-cpython-312\Release\pkcs11/_pkcs11. obj /OUT:build\lib.win-amd64-cpython-312\pkcs11_pkcs11.cp312-win_amd64.pyd /IMPLIB:build\temp.win-amd64-cpython-312\Release\pkcs11_pkcs11.cp312-win_amd64.li b Creating library build\temp.win-amd64-cpython-312\Release\pkcs11_pkcs11.cp312-win_amd64.lib and object build\temp.win-amd64-cpython-312\Release\pkcs 11_pkcs11.cp312-win_amd64.exp _pkcs11.obj : error LNK2001: unresolved external symbol PyUnicode_AsUnicode _pkcs11.obj : error LNK2001: unresolved external symbol PyUnicode_FromUnicode build\lib.win-amd64-cpython-312\pkcs11_pkcs11.cp312-win_amd64.pyd : fatal error LNK1120: 2 unresolved externals error: command 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.37.32822\bin\HostX86\x64\link.exe' failed with exit code 1120 [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip. ERROR: Failed building wheel for python-pkcs11 Failed to build python-pkcs11 ERROR: Could not build wheels for python-pkcs11, which is required to install pyproject.toml-based projects

pyauth / python-pkcs11

Cannot install python-pkcs11 using python 3.12 #165