You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Locally built wolfSSL uses local WolfSSL .so instead of bundling WolfSSL #40
I want to use wolfssl-py with RSA key exchange. Hence, I built wolfssl with the needed flags (and successfully made use of the combiled .so using a C program).
Unfortunately, building wolfssl-py does not work out as expected.
After running USE_LOCAL_WOLFSSL=/usr/local pip3 install ~/Desktop/wolfssl-py/ a package is installed.
But executing my program fails with
Traceback (most recent call last):
[...]
File "/home/lgrote/Documents/app/venv/lib64/python3.11/site-packages/wolfssl/__init__.py", line 144, in __init__
_lib.wolfSSL_Init()
^^^^
NameError: name '_lib' is not defined
Exception ignored in: <function SSLContext.__del__ at 0x7fafdad49580>
Traceback (most recent call last):
File "/home/lgrote/Documents/app/venv/lib64/python3.11/site-packages/wolfssl/__init__.py", line 167, in __del__
if getattr(self, 'native_object', _ffi.NULL) != _ffi.NULL:
^^^^
NameError: name '_ffi' is not defined
Process finished with exit code 1
Indeed, the generated folder in site-packages does not contain _ffi.py.
Any help here would be appreciated. Please let me know if you need any additional information.
changed the title [-]Unable to build wolfssl-py using local wolfssl[/-][+]Locally built wolfSSL uses local WolfSSL .so instead of bundling WolfSSL[/+]on Apr 13, 2023
I really appreciate you getting back to me so fast. Unfortunately, your tips did not help as I had cffi installed already.
I further iterated on the issues and found out that, if ./configure is NOT supplied with --disable-shared and henceforth a .so is installed to \usr\local\lib, wolfssl-py builds and runs just fine using the shared library at runtime. However, the wheel is not self contained as it relies on the shared lib to be present.
I want to build a wheel containing both wolfssl-py and the compiled wolfssl lib. Such a wheel is NOT built if I compile & install wolfssl with ./configure --disable-shared and then run USE_LOCAL_WOLFSSL=1 python3 setup.py bdist_wheel.
For these purposes, I'd love to use the dist target of your Makefile. However, the make folder is not checked into the repo. Is this on purpose?
Hi @laurenzfg, sorry for the lag on this issue. If this is still active, please have a look over the changes in #64, which I think should fix the issues you brought up. Since it's been so long here, I'll mark this closed, but do feel free to re-open if you are still working in this area.
Activity
embhorn commentedon Apr 12, 2023
Hi @laurenzfg
Please see the prerequisites for wolfssl-py:
https://github.com/wolfSSL/wolfssl-py#compiling
This is usually accomplished by running the
setup.pyscript:https://github.com/wolfSSL/wolfssl-py/blob/master/setup.py
If you don't want to use the script, try:
pip install cffiThanks,
@embhorn - wolfSSL Support
[-]Unable to build wolfssl-py using local wolfssl[/-][+]Locally built wolfSSL uses local WolfSSL .so instead of bundling WolfSSL[/+]laurenzfg commentedon Apr 13, 2023
Hey @embhorn,
I really appreciate you getting back to me so fast. Unfortunately, your tips did not help as I had
cffiinstalled already.I further iterated on the issues and found out that, if
./configureis NOT supplied with--disable-sharedand henceforth a.sois installed to\usr\local\lib,wolfssl-pybuilds and runs just fine using the shared library at runtime. However, the wheel is not self contained as it relies on the shared lib to be present.I want to build a wheel containing both
wolfssl-pyand the compiled wolfssl lib. Such a wheel is NOT built if I compile & installwolfsslwith./configure --disable-sharedand then runUSE_LOCAL_WOLFSSL=1 python3 setup.py bdist_wheel.For these purposes, I'd love to use the dist target of your Makefile. However, the
makefolder is not checked into the repo. Is this on purpose?embhorn commentedon Apr 14, 2023
Hi @laurenzfg
I've requested a review of this issue by my colleague, @cconlon
cconlon commentedon Mar 2, 2026
Hi @laurenzfg, sorry for the lag on this issue. If this is still active, please have a look over the changes in #64, which I think should fix the issues you brought up. Since it's been so long here, I'll mark this closed, but do feel free to re-open if you are still working in this area.