inventory breaks linking #341
Comments
|
I think we need to differentiate these problems more. First you're writing:
Then you say:
This seems contradictory to me. It should always be possible to minimize without getting a specialization error. Then you write about the following, which looks like it's a binary compiled with the wrong module name:
For the final linker error, please include the output of |
|
I created a new project, completely separate from my original code-base, in the hopes of generating a truly minimal example. I'll start over again using my original codebase and culling down to the smallest amount of code that I can. I will send you the complete output, and once I have truly minimal example that shows the problems, I'll upload everything to GitHub. |
|
@konstin I've created a repository that explains and illustrates the bug that I'm having at https://github.com/ckaran/pyo3_issue_report_341. Please let me know if I can help further with this. |
|
@ckaran |
|
With the help of the repo, I could minize it to the following code: So it seems that "invoking" inventory seems to break cargo test. This is actually the same issue as #340 with the same workaround. I'm confused that this did work before as there have always been problems with linking and tests. How inventory is able to break the linking is not explicable to me. |
konstin
changed the title
cc failed: exit code: 1
|
@konstin Thank you for the prompt response and the work-around. I have no idea how it was working before, and stopped working. I know that when I did That said, the workaround does work for me, even on my complete project (not just the minimized project). @kngwyu |
|
I've gathered some more information on the problem. The following code block is the trimmed down macro expansion. #![feature(specialization)]
use pyo3::prelude::*;
pub struct PyChannelIdentifier {}
impl pyo3::type_object::PyTypeInfo for PyChannelIdentifier {
type Type = PyChannelIdentifier;
const NAME: &'static str = "PyChannelIdentifier";
const DESCRIPTION: &'static str = "\u{0}";
const SIZE: usize =
{ Self::OFFSET as usize + ::std::mem::size_of::<PyChannelIdentifier>() + 0 + 0 };
const OFFSET: isize = {
((<pyo3::types::PyAny as pyo3::type_object::PyTypeInfo>::SIZE
+ ::std::mem::align_of::<PyChannelIdentifier>()
- 1)
/ ::std::mem::align_of::<PyChannelIdentifier>()
* ::std::mem::align_of::<PyChannelIdentifier>()) as isize
};
const FLAGS: usize = 0;
type BaseType = pyo3::types::PyAny;
#[inline]
unsafe fn type_object() -> &'static mut pyo3::ffi::PyTypeObject {
static mut TYPE_OBJECT: pyo3::ffi::PyTypeObject = pyo3::ffi::PyTypeObject_INIT;
&mut TYPE_OBJECT
}
}
impl pyo3::IntoPyObject for PyChannelIdentifier {
fn into_object(self, py: pyo3::Python) -> pyo3::PyObject {
pyo3::Py::new(py, self).unwrap().into_object(py)
}
}
impl pyo3::type_object::PyObjectAlloc for PyChannelIdentifier {}
pub struct PyChannelIdentifierGeneratedPyo3Inventory {
methods: &'static [pyo3::class::PyMethodDefType],
}
impl pyo3::class::methods::PyMethodsInventory for PyChannelIdentifierGeneratedPyo3Inventory {
fn new(methods: &'static [pyo3::class::PyMethodDefType]) -> Self {
Self { methods }
}
fn get_methods(&self) -> &'static [pyo3::class::PyMethodDefType] {
self.methods
}
}
impl pyo3::class::methods::PyMethodsInventoryDispatch for PyChannelIdentifier {
type InventoryType = PyChannelIdentifierGeneratedPyo3Inventory;
}
impl ::inventory::Collect for PyChannelIdentifierGeneratedPyo3Inventory {
fn registry() -> &'static ::inventory::Registry<Self> {
static REGISTRY: ::inventory::Registry<PyChannelIdentifierGeneratedPyo3Inventory> =
::inventory::Registry::new();
®ISTRY
}
}
impl PyChannelIdentifier {
pub fn foo(&self) -> PyResult<()> {
unimplemented!()
}
}
unsafe extern "C" fn __wrap(_slf: *mut pyo3::ffi::PyObject) -> *mut pyo3::ffi::PyObject {
let _pool = pyo3::GILPool::new();
let _py = pyo3::Python::assume_gil_acquired();
let _slf = _py.mut_from_borrowed_ptr::<PyChannelIdentifier>(_slf);
let _result = { pyo3::derive_utils::IntoPyResult::into_py_result(_slf.foo()) };
pyo3::callback::cb_convert(pyo3::callback::PyObjectCallbackConverter, _py, _result)
}
#[used]
#[allow(non_upper_case_globals)]
#[link_section = ".ctors"]
static __init8310110886103380135: extern "C" fn() = {
extern "C" fn __init8310110886103380135() {
pyo3::inventory::submit({
{
type TyInventory = <PyChannelIdentifier as pyo3::class::methods::PyMethodsInventoryDispatch>::InventoryType;
<TyInventory as pyo3::class::methods::PyMethodsInventory>::new(&[
pyo3::class::PyMethodDefType::Method({
pyo3::class::PyMethodDef {
ml_name: "foo",
ml_meth: pyo3::class::PyMethodType::PyNoArgsFunction(__wrap),
ml_flags: pyo3::ffi::METH_NOARGS,
ml_doc: "\u{0}",
}
}),
])
}
});
}
__init8310110886103380135
};
#[cfg(test)]
mod tests {
#[test]
fn test() {}
} |
|
We're running into this in the wasmtime project: bytecodealliance/wasmtime#468 |
|
Hi! The lib: The cli app: I can build the lib without problems in windows 10 and linux (wsl2), but when i try to build it on linux (wsl2) it fails on the last step (build my cli-app). (I'm consuming the pyclass and the pymethods on rust on my cli app). The error: |
|
We're still actively exploring ways to fix this. For now, please see the FAQ. |
|
I'm running into this problem in |
# Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
|
With the release of PyO3 v0.14, the dependency on |
I have to maintain a python extension using pyo3 both on windows and linux. I have no problem with both Why windows do not has this problem? |
|
@longilacus the two operating systems have different linking convenstions, in particular Python extensions on Windows always link to libpython, but on Linux they must not. |
|
Might be related to the followings (in case it puts some new perspective)
I also experienced the same type of error when I try to statically compile against C libraries, it runs ok with |
馃悰 Bug Reports
I'm having linking errors when using
v0.6.0-alpha.2which I didn't have when usingv0.6.0-alpha.1. The complete set of errors is at the end of this post, but the summary is that many python symbols are missing. I rangit bisectfor all revisions betweenv0.6.0-alpha.1andv0.6.0-alpha.2, and found that the first bad commit was ae8a37c.馃實 Environment
Linux EMANE 4.15.0-45-generic some of PyNumberProtocol methods are broken聽#48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux, Ubuntu 18.04.
Python 3.7.1 [GCC 7.3.0]
Built from source, installed it to the default system location (
/usr/local/bin/python3)rustc --version):rustc 1.34.0-nightly (4b1e39b7b 2019-02-05)
version = "0.x.y"withgit = "https://github.com/PyO3/pyo3")?I did try the latest master (9e53418) and the problem persisted (may have gotten worse, I didn't check the outputs between
v0.6.0-alpha.2and 9e53418).馃挜 Reproducing
I tried creating a minimal example, but the minimal example fails to compile under
v0.6.0-alpha.1with the following:And the same example compiles under
v0.6.0-alpha.2, but fails to lead into python with the followingerror:
This is all very weird, because I can compile and load my regular code without any trouble. If you can tell me what to do to get around these bugs, I can create a new minimal example to show you.
Compiler output:
The text was updated successfully, but these errors were encountered: