Pyo3: #[pymodule] seems to cause link.exe error: 1112 with Python 3.8.1

[TheBats]

🐛 Bug Reports

I followed the guide provided by the README file. I am able to build the project with the following piece of code in my lib.rs file

use pyo3::prelude::*; 
use pyo3::wrap_pyfunction;
#[pyfunction]
/// Formats the sum of two numbers as string
fn sum_as_string(a: usize, b: usize) -> PyResult<String> {
    Ok((a + b).to_string())
}

However, building the project with the following part added to lib.rs file

/// This module is a python module implemented in Rust.
#[pymodule]
fn string_sum(py: Python, m: &PyModule) -> PyResult<()> {
    m.add_wrapped(wrap_pyfunction!(sum_as_string))?;
    Ok(())
}

will result in an error caused by (cargo build --verbose):

process didn't exit successfully: `rustc --crate-name string_sum --edition=2018 src\lib.rs --error-
format=json --json=diagnostic-rendered-ansi --crate-type cdylib --emit=dep-info,link -C 
debuginfo=2 -C metadata=6ac7a18e68c1e33f --out-dir C:\Users\...\Desktop\Projects
\Rust\test\target\debug\deps -C incremental=C:\Users\...\Desktop\Projects
\Rust\test\target\debug\incremental -L dependency=C:\Users\...\Desktop\Projects
\Rust\test\target\debug\deps --extern pyo3=C:\Users\...\Desktop\Projects\Rust\test
\target\debug\deps\libpyo3-9cb39eebe47e1f6a.rlib -L native=C:\Users\...\AppData\Local
\Programs\Python\Python38\libs` (exit code: 1)

In case it is needed, here is my Cargo.toml:

[package]
name = "..."
version = "0.1.0"
authors = ["..."]
edition = "2018"

[lib]
name = "string_sum"
crate-type = ["cdylib"]

[dependencies.pyo3]
git = "https://github.com/PyO3/pyo3"
feature = ["extension-module"]

🌍 Environment

• Your operating system and version: Windows 10
• Your python version: Python 3.8.1
• How did you install python (e.g. apt or pyenv)? Did you use a virtualenv?: Using the executable file, I am not using a virtual env
• Your rust version (rustc --version): rustc 1.42.0-nightly (bc1571cc3 2020-01-05)
• Are you using the latest pyo3 version? Have you tried using latest master (replace version = "0.x.y" with git = "https://github.com/PyO3/pyo3")?
  I tried with version = "0.8.5" and #git = "https://github.com/PyO3/pyo3"

💥 Reproducing

Here is the complete code I am trying to compile:

use pyo3::prelude::*;
use pyo3::wrap_pyfunction;

#[pyfunction]
/// Formats the sum of two numbers as string
fn sum_as_string(a: usize, b: usize) -> PyResult<String> {
    Ok((a + b).to_string())
}

/// This module is a python module implemented in Rust.
#[pymodule]
fn string_sum(py: Python, m: &PyModule) -> PyResult<()> {
    m.add_wrapped(wrap_pyfunction!(sum_as_string))?;

    Ok(())
}

[kngwyu]

Hi, thank you for reporting that!
Can you reproduce it with Python 3.7.*?
If not, we should re-check FFI compatibility with Python 3.8, though it works with Linux.
Related: #704

Hmm but the error messages do not look related to specific FFI declaration :thinking:

[TheBats]

So I did a fresh install of python, and tested it with Python 3.7.6 and still got the same problem.

Caused by:
  process didn't exit successfully: `rustc --crate-name string_sum --edition=2018 src\lib.rs --error-
format=json --json=diagnostic-rendered-ansi --crate-type cdylib --emit=dep-info,link -C 
debuginfo=2 -C metadata=6ac7a18e68c1e33f --out-dir C:\Users\...\Desktop\Projects
\Rust\test\target\debug\deps -C incremental=C:\Users\...\Desktop\Projects\Rust\test
\target\debug\incremental -L dependency=C:\Users\...\Desktop\Projects\Rust\test\target
\debug\deps --extern pyo3=C:\Users\...\Desktop\Projects\Rust\test\target\debug
\deps\libpyo3-9cb39eebe47e1f6a.rlib -L native=C:\Users\...\AppData\Local\Programs\Python
\Python37\libs` (exit code: 1)

Also what might be interesting:

python37.lib(python37.dll) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'x86'

[davidhewitt]

That error at the end is potentially a clue.

Have you installed a 32- or 64-bit Python install? And similarly is your Rust target 32- or 64- bit?

They'll need to match. I suspect this might be the problem you're encountering.

I wonder if we can detect this in build.rs

[TheBats]

@davidhewitt This seems to fix the build issue, I did not know Rust was not installing the 64-bit version by default... Thank you!
Might it be interesting to write in the README.md that it needs Rust in 64-bit ?

[davidhewitt]

I did not know Rust was not installing the 64-bit version by default

Rustup uses the 64-bit target by default on my machine. Can you check the toolchain with rustup show-active-toolchain ? This is what I get on my windows 10:

~\dev\pyo3 [master]> rustup show active-toolchain
nightly-x86_64-pc-windows-msvc (directory override for '\\?\C:\Users\david\dev\pyo3')

Once you're sure Rust is using a 64-bit target then you'll need to check the python interpreter you're running is also 64-bit. (See this this stack overflow answer for how to do that.) Finally, are you copying the correct output file? (target/debug/string_sum.dll)

[TheBats]

At first running the command you told me displayed 'stable-i686-pc-windows-msvc' and in the directory of my PyO3 project it displayed 'nightly-i686-pc-windows-msvc'. Once I downloaded the x86_64 versions of stable and nightly through rustup install stable-x86_64-pc-windows-msvc and rustup install nightly-x86_64-pc-windows-msvc and running rustup override set nightly-x86_64-pc-windows-msvc inside the PyO3 project directory fixed it. Now it is buiding it correctly. So the problen was that the Rust installer seemed to have installed the i686 version instead of the x86_64

[davidhewitt]

@kngwyu Should we rename this ticket to something like "Report error in build.rs when detected python interpreter architecture does not match target architecture" ?

I might put together a PR some time...

[konstin]

Note that I'm doing a 32-bit vs 64-bit and some other architecture checks in maturin, e.g. here, here and also here, so you can just copy from there.

[oconnor663]

A note for other folks running into this: If you see a flood of "unresolved external symbol" errors, it might be this issue. Previously #175 was the only issue that included those specific words :)