-
Notifications
You must be signed in to change notification settings - Fork 3
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.
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
Generate import library without external tools #20
Comments
Please keep in mind that RFC 2627 is still being actively worked on, and when it hits stable it will make hacks like |
Looks like the implementation of RFC 2627 does not support |
Yes, PyO3 uses quite a lot of |
And to support multiple Python versions and abi3 in #[link(name = "python3.dll", kind = "raw-dylib")]
#[link(name = "python37.dll", kind = "raw-dylib")]
#[link(name = "python38.dll", kind = "raw-dylib")]
#[link(name = "python39.dll", kind = "raw-dylib")]
#[link(name = "python310.dll", kind = "raw-dylib")]
#[link(name = "python311.dll", kind = "raw-dylib")] And this MINGW Python dll name thing is annoying too. |
Yes, code like that is best generated by the build script or a macro. |
I've take some time to port
llvm-dlltool
to Rust, implib-rs is a crate implements generating Windows import library from module definition file.Unfortunatelyrust-ar
doesn't support writing symbol table, so the currently it requires to runranlib
after generation to be useful. Thus it's not ready to be integrated inpython3-dll-a
right now. Hopefully someday we can find a solution to it.I wonder how hard it is to port the mingw64 version, it'd be nice to support them both.
Update: implib crate now produces the exact same
.lib
file likellvm-dlltool
and it works for linking withlld
with the thispython3-dll-a
patch:The text was updated successfully, but these errors were encountered: