Skip to content
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

Avoding linker scripts in MinGW libraries #935

Open
mati865 opened this issue Aug 3, 2020 · 7 comments · May be fixed by retep998/windump-rs#1
Open

Avoding linker scripts in MinGW libraries #935

mati865 opened this issue Aug 3, 2020 · 7 comments · May be fixed by retep998/windump-rs#1

Comments

@mati865
Copy link

mati865 commented Aug 3, 2020

LLD doesn't and won't support linker scripts in COFF mode. That creates a problem since winapi has following linker scripts:

winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_mincore.a
winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_mincore_downlevel.a
winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_nanosrv.a
winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_onecore.a
winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_onecoreuap.a
winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_onecoreuap_downlevel.a
winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_onecore_downlevel.a
winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_runtimeobject.a
winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_shcore.a
winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_vfw32.a
winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_windowsapp.a
winapi-x86_64-pc-windows-gnu-0.4.0/lib/libwinapi_windowsapp_downlevel.a

Maybe the they could be consolidated into single objects (just like mingw-w64 does) or replaced with response files?

For now I've set WINAPI_NO_BUNDLED_LIBRARIES=1.

@retep998
Copy link
Owner

retep998 commented Aug 3, 2020

Feel free to improve how they are generated. https://github.com/retep998/windump-rs/blob/master/src/bin/exports.rs

Ideally I'd like raw-dylib to be implemented so I don't need these import libraries.

@mati865
Copy link
Author

mati865 commented Aug 4, 2020

We actually don't need these import libs any more when not using self-contained mode. Maybe Rust should somehow tell if it's using native or self-contained mode so crates like winapi can avoid hacks like this one?

@retep998
Copy link
Owner

retep998 commented Aug 4, 2020

If there is some way to detect whether Rust is not using self-contained mode, then sure I could have winapi automatically disable the bundled import libraries. raw-dylib is still better though.

@mati865
Copy link
Author

mati865 commented Aug 4, 2020

Raw-dylib is great but latest PR seems stuck: rust-lang/rust#71497

cc @petrochenkov Do you think Rust could somehow notify crates it is using native linkage mode so winapi could avoid forcing bundled libraries?

@petrochenkov
Copy link

petrochenkov commented Aug 18, 2020

@mati865

Do you think Rust could somehow notify crates it is using native linkage mode so winapi could avoid forcing bundled libraries?

This seems more complex than setting WINAPI_NO_BUNDLED_LIBRARIES.

winapi needs to decide whether self-contained mode is enabled or not in a build script, right?
If -C link-self-contained is used then it will supposedly be set through RUSTFLAGS or .cargo/config, does cargo provide build scripts access to this configuration somehow?
I'm not even sure cargo applies RUSTFLAGS to build scripts, so even if we set a cfg predicate in rustc when -C link-self-contained is passed, then the build script may not see it.

@mati865
Copy link
Author

mati865 commented Aug 19, 2020

Cargo docs don't mention RUSTFLAGS but RUSTC_LINKER seems available. Soon using linker from outside sysroot will be the same as native link mode. I'll experiment with that.

@mati865
Copy link
Author

mati865 commented Aug 20, 2020

RUSTC_LINKER is set only when manually configured in ~/.cargo/config. So avoiding bundled libs will probably have to wait until raw-dylib becomes a thing.
retep998/windump-rs#1 fixes the original issue reported here so avoiding bundled libs can wait.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants