Cannot install python-pkcs11 using python 3.12

[abargale]

Cannot install python-pkcs11 using python 3.12

[abargale]

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 cython/cython#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 cython/cython#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 cython/cython#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 cython/cython#4310
performance hint: pkcs11_errors.pyx:86:6: Exception check on 'assertRV' will always require the GIL to be acquired.
Possible solutions:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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:
1. Declare the function as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions.
2. 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

[KingCZE]

I had the same issue. Then I did it through conda on python 3.11 and it worked.