Cannot install python-pkcs11 using python 3.12 #165
Comments
|
I tried cloning the repo locally and trying to build - here is what I get again. Summary: Detailed log: python -m pip install --use-pep517 --no-clean E:\xx\xxx\python-pkcs11 --user × Building wheel for python-pkcs11 (pyproject.toml) did not run successfully. note: This error originates from a subprocess, and is likely not a problem with pip. |
|
I had the same issue. Then I did it through conda on python 3.11 and it worked. |
|
IIRC I solved the problem by updating pip to version 24.1.2 |
I tried by updating pip to 24.1.2. |
|
Yes Upgrading the pip version to 24.2 does not resolve the issue. Any plans to make this compatible with 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 cython/cython#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 cython/cython#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 cython/cython#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 cython/cython#4310
performance hint: pkcs11_errors.pyx:85: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:196: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:211: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: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:
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:230: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:268: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:274: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:282: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:303: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:316: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:336: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:363: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:366: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:380: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:427: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:488: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:566: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:582: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: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:
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:606: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:609: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: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:
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:633: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:640: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:646: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:651: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: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:
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:720: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:731: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:747: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:759: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:769: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:855: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:892: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:896: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: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:
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:935: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: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:
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: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:
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:983: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:987: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: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:
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:1026: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: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:
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: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:
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: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:1077: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: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:
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:1105: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:1115: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:1120: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: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:
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:1150: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:1152: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:1172: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:1182: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:1186: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:1210: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: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:
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:1276: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:1338: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: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:
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:1432: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:1439: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:1470: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: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:
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:1487: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:1556: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:1557: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:1562: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
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]
The text was updated successfully, but these errors were encountered: