Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Static Linux SDK

swift.org

Post reply on HN
Print view View original

181–190 of 274 posts

Re: Swift Static Linux SDK

#181

Post by burntsushi »

kibwen wrote: post #123
MrDrMcCoy wrote: post #122

Earlier quoted context omitted.

I've had a 0% success rate compiling other people's Rust apps statically. I always end up with a shared binary or a failed build, even when building with musl.

What problems did you have? As someone who's never in his life used musl before, I just now ran `rustup target add x86_64-unknown-linux-musl` and then built ripgrep with `cargo build --release --target=x86_64-unknown-linux-musl` and it worked without a problem. ldd confirms that it's statically linked. I'm surprised it was as painless as it was, I thought I'd have to install musl separately.

I just tried this myself and I did not have a painless experience. Hah. Without the `musl` Archlinux package installed, I get this:

      --- stderr
      configure: error: in `/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build':
      configure: error: C compiler cannot create executables
      See `config.log' for more details
      thread 'main' panicked at /home/andrew/.cargo/registry/src/index.crates.io-6f17d22bba15001f/jemalloc-sys-0.5.4+5.3.0-patched/build.rs:351:9:
      command did not execute successfully: cd "/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build" && CC="musl-gcc" CFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" CPPFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" LDFLAGS="-O3 -ffunction-sections -fdata-sections -fPIC -gdwarf-4 -fno-omit-frame-pointer -m64 -static -Wall" "sh" "/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out/build/configure" "--disable-cxx" "--enable-doc=no" "--enable-shared=no" "--with-jemalloc-prefix=_rjem_" "--with-private-namespace=_rjem_" "--host=x86_64-unknown-linux-musl" "--build=x86_64-unknown-linux-gnu" "--prefix=/home/andrew/rust/ripgrep/target/x86_64-unknown-linux-musl/release/build/jemalloc-sys-b7d053053989ba56/out"
      expected success, got: exit status: 77
Notice, in particular, that there is `CC=musl-gcc` in the error above. But:

    $ which musl-gcc
    musl-gcc not found
I think the spoiler here is the fact that ripgrep uses jemalloc when you build with musl on 64-bit: https://github.com/BurntSushi/ripgrep/blob/c9ebcbd8abe48c833...

If you comment out those lines and remove the `jemallocator` dependency from `Cargo.toml`, then the build succeeds.

I imagine you'll run into this same problem if you enable ripgrep's `pcre2` feature.

However, after installing the `musl` Archlinux package (which provides `musl-gcc`, among other things of course), then the above command builds just fine. Including with `jemallocator` or even with the `pcre2` feature enabled.

Re: Swift Static Linux SDK

#182

Post by palata »

kibwen wrote: post #124
palata wrote: post #97

Earlier quoted context omitted.

> It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. You still fundamentally need to rebuild (or at least relink) and re-distribute all the packages, whereas with shared libraries... well you just update that one package.

I hear the refrain "you'll have to rebuild your packages" a lot in these discussions, and I confess I don't see how this is a problem. Maybe it's a holdover from C and C++ veterans for whom figuring out how to build any given project is a Herculean effort, but for every other language with a first-class build system it's trivial.

It really sounds like you see it from the point of view of a developer who has never thought about how a Linux distribution works.

Yes, for you as a user it's simpler to link statically and not learn about anything else. But distros are a bit more elaborate than that.

Re: Swift Static Linux SDK

#183

Post by palata »

kibwen wrote: post #125
palata wrote: post #27

Earlier quoted context omitted.

As you say, a typical Rust program can easily depend on hundreds of crates that nobody really checks. That's a security issue. The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust. What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.

> I just don't want you to force me. Rust supports dynamic linking, and has since well before 1.0.

In practice, it feels like everybody assumes that Rust is installed through Rustup and dependencies are statically linked from cargo. I have tried going the dynamic linking way, it's painful when it's not impossible.

Re: Swift Static Linux SDK

#184

Post by palata »

newZWhoDis wrote: post #114
palata wrote: post #27

Earlier quoted context omitted.

As you say, a typical Rust program can easily depend on hundreds of crates that nobody really checks. That's a security issue. The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust. What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.

More software should “enforce” their preferences, many decisions are objectively superior and this “anything goes” attitude has done nothing but hurt OSS/Linux adoption. Everything about the shared lib model is stupid, and has contributed to poor Linux market share to date.

I couldn't disagree more.

> Everything about the shared lib model is stupid

I don't think we can discuss if that's you're stance. But also I don't think you understand the shared lib model if you think like that.

Re: Swift Static Linux SDK

#185

Post by palata »

PaulDavisThe1st wrote: post #144
e63f67dd-065b wrote: post #3

Earlier quoted context omitted.

It's just classic dependency issues. I'm not familiar with swift specifics, but probably a combination of ABI instability and just plain version incompatibility from one distro to the next with your target program. My opinion is the opposite: I think the old paradigm of distros managing a giant set of system libraries is a bad one, and is how we ended up in the land of docker. Go and Rust made the right decisions her…

> Modern languages are not like C/C++ I think there's a bit of a misconception here. Ardour is written in C++ and depends on 80+ other libraries. The dependency situation may be exacerbated by packaging culture that encourages the use of lots of relatively small dependencies, but it is by no means determined by language or even context.

I started a small project both in C++ and Rust.

When in C++ I had 2 direct dependencies it resulted in 6 total dependencies (direct + transitive).

In Rust I had 5 direct dependencies (because some standard stuff is not in the standard lib) and it resulted in... 300 total dependencies.

> but it is by no means determined by language or even context.

Not sure what you mean there. My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help. If you have to manually handle every single dependency, first it forces you to look at them (that's a good thing), and second it encourages you to minimize them.

Re: Swift Static Linux SDK

#186

Post by PaulDavisThe1st »

palata wrote: post #185
PaulDavisThe1st wrote: post #144

Earlier quoted context omitted.

> Modern languages are not like C/C++ I think there's a bit of a misconception here. Ardour is written in C++ and depends on 80+ other libraries. The dependency situation may be exacerbated by packaging culture that encourages the use of lots of relatively small dependencies, but it is by no means determined by language or even context.

I started a small project both in C++ and Rust. When in C++ I had 2 direct dependencies it resulted in 6 total dependencies (direct + transitive). In Rust I had 5 direct dependencies (because some standard stuff is not in the standard lib) and it resulted in... 300 total dependencies. > but it is by no means determined by language or even context. Not sure what you mean there. My feeling is that making it super easy…

> My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help

What is it that makes you think that C/C++ does not do this also?

[ EDIT: this also has something to do with the typical size and scope of C/C++ libraries ]

Re: Swift Static Linux SDK

#187

Post by kibwen »

amszmidt wrote: post #168
kibwen wrote: post #157

Earlier quoted context omitted.

The distro repositories are being continuously rebuilt, because packages are receiving continuous updates. In the meantime, as far as I'm concerned dynamic linking is itself a security failure, because if I run a binary I want to know exactly what code is being run, without having to worry about dynamic linking and loading nonsense inserting itself into my process.

They aren’t being rebuilt with that kind of frequency as you might think. They get rebuilt when a change in the package is made, not when a change in a dependency is made — which is a huge difference. There are plenty of packages that might not get an update for a long time (month, half year, … whatever their release cadence might be). Dynamic linking makes it _easier_ to handle security, including checking if your p…

I'm against dlopen as well. If something makes use of LD_LIBRARY_PATH, rest assured that I want it excised from my system. Reproducibly-built, fully-static binaries are what I want, ideally with an accessible SBOM embedded.

Re: Swift Static Linux SDK

#188

Post by lmz »

newZWhoDis wrote: post #114
palata wrote: post #27

Earlier quoted context omitted.

As you say, a typical Rust program can easily depend on hundreds of crates that nobody really checks. That's a security issue. The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust. What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.

More software should “enforce” their preferences, many decisions are objectively superior and this “anything goes” attitude has done nothing but hurt OSS/Linux adoption. Everything about the shared lib model is stupid, and has contributed to poor Linux market share to date.

Dynamic linking seems to work fine for Windows or OSX. Maybe it's open source + dynamic linking that's the problem.

Re: Swift Static Linux SDK

#189

Post by josephg »

boffinAudio wrote: post #179
josephg wrote: post #43

Earlier quoted context omitted.

Which languages do you think are both better and have better cross platform support?

Lua, I would say. Far easier to get it everywhere, and a very nice language, also.

Lua is nice, but it’s a bit of a weird comparison for Swift. Swift is compiled and lua is interpreted. Swift is statically typed. Swift uses ref counting to Lua’s runtime GC. And Swift has non nullable types by default, classes, enums, ADTs, match expressions and so on.

Lua is nice. But it’s chalk and cheese comparing the languages. I can’t think of many cases where you’re trying to decide between lua and Swift.

Post reply on HN