Comments (4)
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
from python-pkcs11.
I had the same issue. Then I did it through conda on python 3.11 and it worked.
from python-pkcs11.
Related Issues (20)
- Broken by unpinned Cython 0.29.31: CYTHON_ATOMICS error: lvalue required as left operand of assignment HOT 10
- OverflowError: Python int too large to convert to C ssize_t
- lack of support for generation of `CKK_GENERIC_SECRET` key type.
- Errors in _pkcs11.pyx file: change operand "is" by "=="
- Error received when installing: 'TypeError: can only concatenate tuple (not "list") to tuple' is back HOT 2
- Small Typo in _pkcs11.pyx HOT 5
- How to import X.509v3 digital certificate inside the token or hsm
- 0.7.0: issue with testingπ€ HOT 6
- Can't extract public key from Nitrokey HSM after creation HOT 3
- test opensession softhsmv2 HOT 1
- BUG: sign DATA over 512 bytes doesn't work HOT 3
- Typo in "Applied" docs - Generating Keys
- Python3.6 and earlier do not have annotations HOT 3
- Question regarding get_keys()
- New realese with support for python >= 3.10 on Windows HOT 4
- New release needed HOT 6
- Unable to use 64-bit PKCS#11 libraries (drivers) HOT 2
- segfaulting only on github action
- get_objects() fails with missing enum value HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-pkcs11.