feat: make it possible to add custom logging handler #18
Conversation
|
I pushed a commit up for the broken CI tests, which fixed ubuntu and macOS, but that windows failure is surprising! Edit: looking at the build that released extism_sys rc6, I don't see any smoking guns in the logs. I wonder if the function is, in fact, missing from the DLL? I'll take a look at the artifact shortly. Edit 2: It looks like it's present in the shared object. Running (This is pretty unscientific, though – it might not be exported. I'm not too handy with introspecting the DLL format; if you know of any tools that run on ubuntu or linux please let me know!) |
|
@chrisdickinson - something like this might help? readelf -S -C -s /path/to/lib.so | grep extism_ |
|
A-ha, thanks, that set me on the right path: I used readpe to introspect the (windows) DLL on my (macOS) laptop. It claims that the function is, in fact, exported by the DLL ( (Unfortunately this only deepens the mystery. I'll have to spin up a windows VM to investigate further.) |
|
OK, I think I might've narrowed this down: the shared object has the function, but the python wheel doesn't list it in its generated metadata. I have a theory: this looks like the only place we directly accept a function pointer as a function parameter, and MSVC might struggle to parse that type when Maturin goes to generate the wheel. I'll test this out tomorrow with a dev build of |
This fixes a test failure on the python-sdk [1]. (See also [2]). In particular, while maturin creates bindings for `extism_log_drain` on clang platforms, it seems that MSVC cannot generate the required binding information for `ffi.py`. This results in an `extism_sys` wheel whose shared object (in this case, a DLL) contains the `extism_log_drain`, but whose Python FFI bindings don't contain a definition for that function. Naming the function pointer type parameter resolves the issue. [1]: https://github.com/extism/python-sdk/actions/runs/7172934060/job/19669775001#step:9:35 [2]: extism/python-sdk#18 (comment)
This fixes a test failure on the python-sdk [1]. (See also [2]). In particular, while maturin creates bindings for `extism_log_drain` on clang platforms, it seems that MSVC cannot generate the required binding information for `ffi.py`. This results in an `extism_sys` wheel whose shared object (in this case, a DLL) contains the `extism_log_drain`, but whose Python FFI bindings don't contain a definition for that function. Naming the function pointer type parameter resolves the issue. [1]: https://github.com/extism/python-sdk/actions/runs/7172934060/job/19669775001#step:9:35 [2]: extism/python-sdk#18 (comment)
This fixes a test failure on the python-sdk [1]. (See also [2]). In particular, while maturin creates bindings for `extism_log_drain` on clang platforms, it seems that MSVC cannot generate the required binding information for `ffi.py`. This results in an `extism_sys` wheel whose shared object (in this case, a DLL) contains the `extism_log_drain`, but whose Python FFI bindings don't contain a definition for that function. Naming the function pointer type parameter resolves the issue. What a strange issue! [1]: https://github.com/extism/python-sdk/actions/runs/7172934060/job/19669775001#step:9:35 [2]: extism/python-sdk#18 (comment)
Support for extism/extism#578