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

don't assume musl target is always static #7

Closed
gyakovlev opened this issue Jun 7, 2019 · 5 comments
Closed

don't assume musl target is always static #7

gyakovlev opened this issue Jun 7, 2019 · 5 comments

Comments

@gyakovlev
Copy link

gyakovlev commented Jun 7, 2019

Hi,
build currently assumes that we want static linking if we are building for musl.

env::var("PCRE2_SYS_STATIC").unwrap_or(String::new()) == "1"
|| target.contains("musl");

it's not always desired.
is it possible to provide some kind of override so we can skip static linking on musl targets on demand?

@BurntSushi
Copy link
Owner

What are the cases in which one wants to dynamically link with musl?

My guess is that this is possibly a red herring. I'm not sure if the Cargo toolchain itself supports dynamically linking with musl? A proof of concept of what you're asking for would help.

@gyakovlev
Copy link
Author

it's true than rustup/upstream provided rust tarballs for musl target target static musl, but it's possible to build rust suite itself with crt-static = false in config.toml or just with custom spec. it built that way cargo wil

some linux distros ship rust on musl build with another triple which also ends on musl
so x86_64-unkown-linux-musl is a static linking toolchain as upstream intended and cannot change because of backwards compatibility promise, but x86_64-void-linux-musl is a dynamic one, for example. not sure about alpine linux.

I want to have ripgrep buildable on gentoo musl, it uses musl as system libc, completely replacing glibc.
and apps normally link to musl dynamically, just like they do on glibc system.

lddtree /bin/bash
bash => /bin/bash (interpreter => /lib/ld-musl-x86_64.so.1)
    libreadline.so.7 => /lib/libreadline.so.7
        libncurses.so.6 => /lib/libncurses.so.6
    libc.so => /usr/lib/libc.so

here's an example of rust app.

lddtree /usr/bin/lsd
lsd => /usr/bin/lsd (interpreter => /lib/ld-musl-x86_64.so.1)
    libgcc_s.so.1 => /usr/lib/gcc/x86_64-gentoo-linux-musl/8.2.0/libgcc_s.so.1
    libc.so => /usr/lib/libc.so

I'm not asking to change default behaviour, just give us a knob to override an assumption that if target contains musl it's static.

some links
rust-lang/rust#59302

and here's the PR that enabled overriding static linking in rust on musl
rust-lang/rust#40113

@BurntSushi
Copy link
Owner

All set. If you explicitly set PCRE2_SYS_STATIC=0, then static linking will be forcefully disabled.

@the-eater
Copy link

I would like to gently ask if the default could be changed, there's quite a few musl repo's e.g. alpine, void, chimera. and making the assumption that musl == static seems weird

If that isn't possible could this functionality at least be documented to the README or somewhere in the docs?

@BurntSushi
Copy link
Owner

@the-eater You've got it backwards. The intent isn't, "when we use musl we should statically link." The intent is, "if the user wants a fully static executable, then we'll use musl to achieve that end."

With that said, there is indeed an assumption that if the caller requests musl, then they get a static build. This is somewhat of a convention in the Rust ecosystem. I'm happy to try something different, but it would greatly help matters if you could point to more established projects in the Rust ecosystem that handle musl in a way that makes you happy.

Adding notes to the README is fine, although they might belong in the pcre2-sys README.

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

No branches or pull requests

3 participants