Please correct me if I'm wrong. Aren't binaries in /sbin and /usr/sbin statically linked as opposed to no requirement like this for files living in /bin and /usr/bin?
I always thought the rationale was that if statically linked binaries are on different partition they can be used to recover the system from a failure.
Edit: files in /bin are also statically linked, and I am unsure about what I wrote above but vaguely recall something like that
> /bin/
User utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run.
> /sbin/
System programs and administration utilities fundamental to both single and multi-user environments. These programs are statically compiled and therefore do not depend on any system libraries to run.
It's nice to be able to still run on a crippled system without access to dynamically linked executables, so you can recover. But in practice, wouldn't just about anyone simply boot to a more capable recovery system (via another partition, USB drive, netboot, etc...)?
That was indeed the tradition, but on Linux the GNU libc wants to be only dynamically linked, which creates a lot of problems for those who want static executables.
Because of that, in many Linux distributions there are few, if any, static executables. Due to this, it may happen that a botched glibc upgrade makes the system unusable, because no executable can be started to repair it (nowadays many distributions have a static busybox for such situations). I have seen this a couple of times, and the first time I could not understand what happened, because I was used to older systems, where the commands that I tried to execute (e.g. ls or mv) had been statically linked. Such a thing could never happen in a traditional UNIX or Linux system, before glibc disallowed static linking.
The GNU libc should have been split into a libc with most of the functions, which may be linked statically without problems, and into a small library with the name resolving functions, which could be linked dynamically only by the programs which need those functions.
Even better, the name resolving functions should have been organized in such a way to be able to use their default configuration with static linking and choose dynamic linking only when you really intend to override the default configuration when using less common services, e.g. NIS.
This happened to me on arch recently. I updated pacman but it didn’t warn me it needed an updated glibc. Now pacman refuses to run.
It should be easy enough to repair but it was just an old laptop I wanted to test something on so I ended up throwing the laptop back in the draw instead.
The good thing about arch packages being just tar archives is when pacman fails, you can often fix it by `tar xf` ing the right packages at the root. It's ugly but it works most of the time
I once heard about a "ln" variant called "sln", statically linked, as opposed to the normal ln one, so you could fix a system where the dynamic loader is broken and thus ln is unusable. I can't find it on Ubuntu, though.
then: statically linked bins into /bin, all the others in /usr/bin and 2 symlinks /sbin -> /bin, /usr/sbin -> /usr/bin. It requires duplicate binaries: one version statically linked and the other not: I still want "env" to exist as statically linked, but tons of scripts start with this horrible '#/usr/bin/env MYPREFEREDSCRIPTENGINE'
I always thought the rationale was that if statically linked binaries are on different partition they can be used to recover the system from a failure.
Edit: files in /bin are also statically linked, and I am unsure about what I wrote above but vaguely recall something like that