|
|
|
|
|
|
by disnsn
472 days ago
|
|
|
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 |
|
|
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.)