Description of problem:
Not sure what the appropriate component is for this, feel free to reassign as
The majority of commands in /sbin and /usr/sbin are *DYNAMICALLY LINKED*. This
makes it impossible to do anything useful when the shared libraries become
corrupt. As I found out this week. At the very least /sbin/init should be
statically linked. I couldn't even shutdown my machine.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. # ldd /sbin/*
2. Note that most commands are dynamically linked.
Dynamically linked commands.
Statically linked commands.
As a test; delete your /lib/*.so* on a box you don't care about, then see what
you can do. Exactly nothing. Oh wait. You can handle your adsl connection,
because *those* commands are statically linked. Heaven forbid shutdown, reboot
or init be statically linked. Wouldn't want to be able to turn off a broken
Not sure why this got reported against libtool, it feels more like a distro-wide
thingie. It would be better to file separate bugs against individual components
in violation of the rules, marking them as blocking this bug.
Thank you for reassigning to a more appropriate component.
Static linking is generally discouraged:
Because of this, shipping things statically linked isn't really practical or
For system recovery purposes, things such as sln & busybox are shipped, as well
as rescue mode in the installer.
Okay. I did not spot busybox in amongst the output of "echo /sbin/*". Busybox
satisfies my requirement for statically linked recovery apps.
That said, the person who authored the text at the URL above is completely
ignoring one reason to have statically linked apps, the reason I reported
this in the first place, STATICALLY LINKED APPS WORK WHEN YOUR SHARED
LIBRARIES HAVE BEEN CORRUPTED. DYNAMICALLY LINKED APPS DO NOT. This is not
a theoretical exercise, it's happened to me twice this week.