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
Enabling features = ["extension-module"] on pyo3 in a crate that uses inline-python gives a linker error, because "extension-module" is then also enabled within inline-python-macros, which contains the proc macro that will use pyo3 to compile the Python code to bytecode. That crate is not an extension module, so leaving the symbols undefined will not work, as it won't be loaded by Python, but by Rustc.
This makes me think that "extension-module" should not be a feature, as cargo features should be strictly additive. That the end user is making an extension module, doesn't always mean that everything in the dependency tree will end up in an extension module, although this might very well be limited to procedural macros.
However, I don't know of a solution. Even if the ffi part would be split off into a separate crate, it'd still need to be compiled with different linker flags for the procedural macro than for the final crate. Having a separate crate just for linking to the Python libraries might work, but will probably cause confusion and other problems.
Any ideas?
The text was updated successfully, but these errors were encountered:
davidhewitt
changed the title
"extension-module" feature causing problems
"extension-module" feature causing problems for proc_macro crate
Aug 30, 2020
See fusion-engineering/inline-python#27
Enabling
features = ["extension-module"]
onpyo3
in a crate that usesinline-python
gives a linker error, because"extension-module"
is then also enabled withininline-python-macros
, which contains the proc macro that will usepyo3
to compile the Python code to bytecode. That crate is not an extension module, so leaving the symbols undefined will not work, as it won't be loaded by Python, but by Rustc.This makes me think that
"extension-module"
should not be a feature, as cargo features should be strictly additive. That the end user is making an extension module, doesn't always mean that everything in the dependency tree will end up in an extension module, although this might very well be limited to procedural macros.However, I don't know of a solution. Even if the
ffi
part would be split off into a separate crate, it'd still need to be compiled with different linker flags for the procedural macro than for the final crate. Having a separate crate just for linking to the Python libraries might work, but will probably cause confusion and other problems.Any ideas?
The text was updated successfully, but these errors were encountered: