Re: readline shared library
Daniel Quinlan writes:
> Question: Should Debian use the readline shared library (`librl.so.1.2')?
>
> REASONS FOR (to date)
>
> * Can be used for `ftp', `bash', `python', etc. -- reduces the size
> of /usr/bin and /bin.
>
> True.
>
> * Saves space on the root partition. (corollary of above reason)
>
> True. (At worst, it shouldn't increase the size of / or /usr.)
> Does anyone have any hard figures?
Well, here are figures for ftp (from nic.funet.fi in the directory
/pub/OS/Linux/PEOPLE/Linus/net-source/NetBSD):
$ size *
text data bss dec hex
49152 8192 13408 70752 11460 ftp.noreadline
49152 8192 13456 70800 11490 ftp.shared
94208 20480 15840 130528 1fde0 ftp.static
$ ls -l *
-rwxr-xr-x 1 rsanders users 57348 Mar 19 11:16 ftp.noreadline
-rwxr-xr-x 1 rsanders users 57348 Mar 19 11:14 ftp.shared
-rwxr-xr-x 1 rsanders users 114692 Mar 19 11:15 ftp.static
$ ls -l /lib/librl.so.1.2 /usr/lib/libreadline.*a
-rwxr-xr-x 1 root root 103428 Feb 25 17:28 /lib/librl.so.1.2
-rw-r--r-- 1 root root 128754 Mar 19 11:05 /usr/lib/libreadline.a
-rw-r--r-- 1 root root 45540 Dec 1 08:25 /usr/lib/libreadline.sa
All the executables listed here are QMAGIC binaries; you can save a little
space by making them OMAGIC, but then they're not demand pageable. That
brings up an auxiliary point: Debian should start linking all its binaries
with the "-qmagic" flag to ld (or "-Wl,-qmagic" flag to gcc unless you've
put in into your specs) for several reasons:
1) saves space
2) catches NULL dereferences
3) works better on 4K filesystems
> * Increases functionality of `ftp'.
> True.
And it can be used in ncftp as well, which *really* increases the functionality
of ftp.
> REASONS AGAINST (to date)
>
> * If we link /lib/librl.so.1.2 into `bash' and `librl.so.1.2' can't
> be found, then `bash' won't work.
> * Essential things shouldn't use any other dynamic libraries than
> `libc.so.x.y'
I also disagree with these points.
> After examining all of these facts, my opinion is that it would be a
> good change. If we already use readline functions in `bash', why not
> use readline in `ftp', put `librl.so.1.2' into /lib, and dynamically
> link everything that can (or already does) use readline into it?
>
> Now, does anyone have any real reasons *not* to do it?
Okay, although I originally proposed it, I've found one. When I was
compiling ftp and bash to get some size differences, I found that bash
1.13.5 needed some entries not in librl.so.1.2, so I generated a
librl.so.1.3 with a few new entries. Well, that prompted me to look
through the source, and it turns out that readline compiles differently
depending on whether it's intended to be used in bash: several things
are wrapped in "#ifdef SHELL".
That said, I think using librl in ftp, ncftp, gdb, and other executables
is a good idea, but it looks like bash won't have full functionality
unless it uses the statically linked libreadline. I'll write Chet Ramey
and ask him to remove the interdependencies with bash, and maybe send
him some patches if I find the time, but until then, bash probably shouldn't
be linked against librl.so. Just for the curious, here are the numbers for
bash:
$ ls -l *
-rwxr-xr-x 1 rsanders src 212996 Mar 19 13:03 bash.shared
-rwxr-xr-x 1 rsanders src 274436 Mar 19 13:03 bash.static
$ size *
text data bss dec hex
204800 8192 1096 214088 34448 bash.shared
253952 20480 3472 277904 43d90 bash.static
It looks like each program saves about 60K when linked with the shared
readline library; two program linked against it make up for the size of
librl.so. I know I already have 4 or more linked against it.
Reply to: