rust-lang / pkg-config-rs

Build library for invoking pkg-config for Rust
https://docs.rs/pkg-config
Apache License 2.0
173 stars 79 forks source link

Static linking is too restrictive #102

Open yshui opened 4 years ago

yshui commented 4 years ago

https://github.com/rust-lang/pkg-config-rs/blob/ef356f3024507f11a8a9d15d733f6d2293213320/src/lib.rs#L570-L581

Basically any library which falls into /usr/lib/ won't be statically linked (which is basically all libraries found by pkg-config). Why is this logic there?

sdroege commented 4 years ago

That seems to come from 9a57960f by @alexcrichton . I don't understand the rationale given in the commit message though. Maybe he can explain :)

alexcrichton commented 4 years ago

Hm given how that was around 7 years ago, I don't really remember much about the context... 99% of the time commits like that were "this fixes a bug somewhere" and I didn't do a great job of documenting what bug was fixed where. I don't currently remember what bug was fixed either, so sorry but I don't think I can be of much help :(

yshui commented 4 years ago

Maybe we can remove it now?

sdroege commented 4 years ago

Possibly, but most likely it will break someone's setup :)

I'd like to do a pkg-config 0.5 release in the future that drops all these weird hacks that come without explanation and instead rely solely on the default pkg-config behavior (and if needed people can override that with the pkg-config environment variables, we don't have to set them ourselves, or with a wrapper script). Currently this crate is rather opinionated about the build environment, which causes a couple of problems.

cjordan commented 3 years ago

I've just come up against this issue. Is there something I could do to help accelerate the next big release of pkg-config?

toxeus commented 3 years ago

@sdroege wrote:

Possibly, but most likely it will break someone's setup :)

Maybe we can introduce another env var to disable the current behavior that refuses to statically link system libs? A quick and quite dirty workaround already exists by setting, e.g. SYSROOT=/asdf but it would be nicer to have something explicit rather than relying on such side-effects.

otavio commented 2 years ago

@sdroege, any news in providing a way to get it linking to static libraries more easily?

jirutka commented 2 years ago

@alexcrichton, can you please remove this “feature” or at least allow us to disable it via an environment variable? It is clearly wrong and based on some weird assumption that doesn’t hold universally. The workaround with SYSROOT=/dummy cannot be used when cross-compiling.

toxeus commented 2 years ago

@sdroege established a plan on how to move forward but nothing happened since 2 years.

teythoon commented 1 year ago

This affects our Nettle bindings as well: https://gitlab.com/sequoia-pgp/nettle-sys/-/issues/16

Wenzel commented 7 months ago

Any update on ticket ? It's been almost 4 years now, the issue has been idenfified and the maintainer agreed for the removal of this chunk of code.

Anything blocking you @sdroege ? I saw you made 2 releases recently, any chance you can remove is_static_available() and bump the version ? It would unblock many people I think.

sdroege commented 7 months ago

It requires doing a breaking release, and as part of that it would be a good idea to go through everything in more detail and check if it makes sense to change other things. I didn't have time for that so far.

teythoon commented 7 months ago

Well, perfect is the enemy of good. The crate hasn't even reached version 1 yet, so maybe it is okay to cut a new minor release even if you don't fix other breaking changes with it.