[ninkendo]

> Rust executables are only 100% static on OSes that expose system libraries as static libraries

This seems to be a weird hair to split. GP clearly means “a single executable you can run on any install of the target OS without dependencies.” Whether it’s a truly honest-to-goodness static binary that don’t link to libc or libSystem or whatever is important to approximately zero people, outside of internet pedants.

[disnsn]

I agree that this is what many people -- including me -- are caring about.

However, it is not achieved in practice with "static" languages like rust and golang for me

I frequently run into dynlib issues with regards to incompatible glibc references when sharing binaries between different OS like Ubuntu and Fedora or even just different versions of the same OS

[ninkendo]

> I frequently run into dynlib issues with regards to incompatible glibc references when sharing binaries

Assuming you’re talking about rust binaries, this would only happen if your binary is using glibc symbols that don’t exist on an older version of glibc, and then try to run that binary on a system with the older glibc.

But glibc is a red herring here, because rust is only using libc to call syscalls on the host, because that’s how you’re supposed to do it on every OS, and that’s how you have to do it on every OS but Linux. (Only Go seems to want to implement their own syscalls on Linux.)

It’s a red herring though, because even if rust made their own syscalls and didn’t use glibc on Linux, you’d just fail with ENOSYS when these syscalls are used, instead of failing with undefined symbols at load time. If you try to run stuff that was developed against newer kernel features, on a system without these syscalls, you’re going to run into an equivalent issue. (You might get lucky and not need those syscalls in your app, but that’s not always going to be the case.)

[pjmlp]

It is, because so many folks make such a big deal of how using computers as they used to be until early 1980's, with single static linking model.

Ironically the same folks don't see to appreciate how object files and binary libraries work in static linking, lets make it even better compiling always from source.

[ninkendo]

Nobody’s making a big deal about in it in this thread but you.

[pjmlp]

I beg to differ,

> Good dependency management, a rich package ecosystem, defaults to static binaries which are easy to distribute and a tendency to be fast (even if it’s just the lack of startup overhead) make it a popular choice.

> .....

> Plus Rust can generate a static executable, which is reasonably small, and doesn't require a third party runtime.

Somewhere this thread....

And guess what, you can also ignore my comments.

[ninkendo]

People are using a term in a different way than you want them to.

They use static binary to mean “the dependencies I specify in my package manager are all put in the one binary, and it doesn’t require a separately installed runtime to run”, which is totally reasonable, and it is opposed to so many languages that don’t work this way.

You’re using static binary to mean “does not link to anything at all”, which on some systems results in worse portability, since the syscall interface is unstable and linking to libc/libsystem/etc is the only supported way to make syscalls.

You come into the discussion assuming definition B, ignore the fact that they’re using definition A, say that they’re making a big deal about definition B, etc.

There’s no confusion from anyone here but you. We all are using definition A. You’re the only one using definition B. It’s probably better if you just recognize that and move on rather than insisting everyone here is an idiot but you.