Re: strip makes libs unusable

[Joseph Fago <cfago at tconl dot com>]

> "Jones, Clay" wrote:
> 
> I seem to recall that when I rebuilt the latest e2fs utilities, I made them
> with the ELF_SHARED option.  The resulting shared library and executables were
> huge though.
> 
> So I stripped mke2fs, e2fsck, and libext2fs.so.2.

Tell me this isn't happening... please folks, don't go stripping your
shared libs. You may save a few 'bytes', on large libs maybe a few KB,
but it isn't worth it.

What do you do when some program needs a function, but you don't know
what library to link with? Which one is it in? You could have run 'nm'
to find out... but wait, all the symbols are gone. running an 'nm' on
a library which has been stripped with the '--strip-unneeded' switch
produces nada! albiet it is still usable, as opposed to just doing a
straight strip on a shared lib--this has always rendered my shared
libs unusable (it may work today... but I wouldn't know, and even if
I did, I wouldn't count on it working tomorrow).

Here are my results right off of tsx-11.mit.edu for the e2fsprogs-1.15
source:


static e2fsck:           397596
shared e2fsck:           139225 
stripped shared e2fsck:  109556 

ldd shows:
ldd ./e2fsck
        libc.so.6 => ../lib/libc.so.6 (0x40015000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


Clocking in at 110K isn't too bad for a utility as important as this,
and it only linked with the usual ld and c libs. libe2* were kept
static. This is the default from ./configure

Scenario 2 -- what you did ( --enable-elf-shlibs )
--------------------------
shared e2fsck:            87118
stripped shared e2fsck:   75472

ldd shows:
ldd ./e2fsck
        libext2fs.so.2 => ../lib/libext2fs.so.2 (0x40015000)
        libcom_err.so.2 => ../lib/libcom_err.so.2 (0x40027000)
        libuuid.so.1 => ../lib/libuuid.so.1 (0x40029000)
        libc.so.6 => /lib/libc.so.6 (0x4002e000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


Great, except that the required libs add another 102588 of required
disk space. So lets run 'strip --strip_unneeded' on libext2fs.so.2...

before:  83249
after:   70144

Is this the 'great reduction' you referred to? 13K ? and a 110K
executable (e2fsck) is huge?

nm shows:
nm ./libext2fs.so.2
./libext2fs.so.2: no symbols

Now that's what I call a great reduction allright! But you know, it
still runs, so things can't be all bad... until some poor soul forgets
the --strip-unneeded switch and his stuff won't run anymore... it can
happen. I am speaking from experience here ;) I was sooo proud of
being able to strip my libraries until I got burned.

In fairness to you, I did strip the largest lib on my system -- the
almighty libc-2.1.2.so. It went from 1168349 to 963576, still, 200K
seems a small price to pay these days for the added security of a .so
with all its relocation information and symbols in-tact.

> 
> Their sizes all greatly reduced, and everything worked (is working) fine.

You got lucky!

> On Thu, Sep 23, 1999 at 01:25:45PM -0400, Allin Cottrell elucidated:
> >
> > I can't claim great expertise on this, but it seems that (a)
> > it's OK to strip shared libs (.so) if you want, but (b) if you

Yes you sure can, but run `nm` on any "production" server out there, and
tell me how many shared libs have been stripped... The answer is _none_, and
I'll guarantee there is some logic behind that.
 
> Could you actually strip a shared lib?  I'm no expert either, but I would
> have figured you'd just have the same problems.  I'm too chicken to test it
> on my machine. ;-)

So are the pro's ;-)


Sorry for being so cynical, but I just don't want to spend the next few
months sifting through the "HELP - I stripped my libs" messages on this
list. Besides, we should stress-test this thing, not make it undebuggable, and
possibly unusable. Maybe there's a list out there for saving every last
inode at the expense of system stability, but this isn't it (IMHO).

JF