Yesterday I discovered that the fdisk in /sbin (potato) is not
statically linked. Neither is cfdisk. I thought that all programs in
/sbin were supposed to be statically linked. Why is this not the case?
This put me in a poor position installing Debian for an old Slackware
user. Neither program from slink (the current distribution) would
properly recognize his 12GB hard drive. We didn't want to manually edit
drive geometry (although I've done that before).
What's more confusing, is that ldd reveals only 2 libraries that are
depended on:
$ ldd /sbin/fdisk
libc.so.6 => /lib/libc.so.6 (0x40017000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ ldd /lib/libc.so.6
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)
$ ldd /lib/ld-linux.so.2
statically linked
When I also copied over those libraries, the new fdisk still failed to
run, complaining of _dl* symbols. When I also brought over
/lib/libdl.so.2, it still complained. Why is ldd not revealing the whole
story?
Finally, it occurred to us that if we could just link a static fdisk,
we'd be fine. Is there a way to take an executable and shared libraries,
and bundle up a static version? That is exactly what ld does when you
launch a program, but I want the results as another program, not a
process. The man page for ld lists options for turning an archive
library into a shared library; I want to go the other way, and bundle it
all together as one static executable. How?
In the end, we could have just taken the potato install disks, used them
to partition the hard drive, then reverted to the slink CDs. But we ran
out of time after an hour and a half of screwing with fdisk. Are these
problems (with large hard drives) resolved now? I remember having
similar problems when I installed half a year ago, but only if I created
certain partitions. There were warnings upon booting, that disappeared
eventually when fdisk was upgraded.
--
Marc Lepage (aka SEGV)
http://www.antimeta.com/
RTS game programming info, Minion open source game, etc.
