Skip to content

Add note to FAQ about failing integration tests #1336

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Add note to FAQ about failing integration tests #1336

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions guide/src/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,22 @@ extension-module = ["pyo3/extension-module"]
default = ["extension-module"]
```

## I can't run `cargo test`: Compiler fails to import crate for tests in `tests/` directory!

The Rust book suggests to [put integration tests inside a `tests/` directory](https://doc.rust-lang.org/book/ch11-03-test-organization.html#integration-tests). However, you can't do that for a PyO3 project. The compiler wouldn't be able to find your crate and displays an error like this:

```
error[E0463]: can't find crate for `my-crate`
--> tests/tests.rs:4:1
|
4 | use crate;
| ^^^^^^^^^ can't find crate
```

This is not a bug in PyO3. But it's a [known problem of Cargo](https://github.com/rust-lang/cargo/issues/6659).

For now you can work around it by putting the integration tests inside the `src/` directory.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think an alternative workaround is also to add rlib to the crate-types in your Cargo.toml?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is also what a colleague suggested. However that yielded a new error:

  = note: /usr/bin/ld: /home/developer/projects/pyo3-ftp/target/debug/deps/libpyo3-9f95204c15f7bad5.rlib(ceval.o): relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
          /usr/bin/ld: final link failed: Bad value
          collect2: error: ld returned 1 exit status

Any idea if this could that also happen to others? Or is this problem isolated for my project?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I understand, thanks.
It looks like that we cannot link Python with rlib.
How about lib?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GLIBC 2.2.5 is apparently from 2002... what OS are you using / where did you get the python interpreter from?

https://sourceware.org/glibc/wiki/Glibc%20Timeline


## Ctrl-C doesn't do anything while my Rust code is executing!

This is because Ctrl-C raises a SIGINT signal, which is handled by the calling Python process by simply setting a flag to action upon later. This flag isn't checked while Rust code called from Python is executing, only once control returns to the Python interpreter.
Expand Down