wtf ... Something strips installed binaries???

[Richard W.M. Jones]

On Tue, Sep 02, 2008 at 10:48:55AM +0100, Daniel P. Berrange wrote:
> On Tue, Sep 02, 2008 at 09:01:50AM +0100, Richard W.M. Jones wrote:
> > 
> > I installed a binary from an RPM last night.  Here's what I installed:
> > 
> > # rpm -qlvp ~rjones/rpmbuild/RPMS/i386/ocsigen-1.1.0-3.fc10.i386.rpm | grep /usr/bin
> > -rwxr-xr-x    1 root    root          2294198 Sep  1 23:32 /usr/bin/ocsigen
> > 
> > This morning:
> > 
> > # ll /usr/bin/ocsigen 
> > -rwxr-xr-x 1 root root 298908 2008-09-01 23:32 /usr/bin/ocsigen
> > 
> > This stipped binary is broken -- these binaries must NEVER be stripped!
> 
> Why mustn't it be stripped ? If it genuinely needs the symbol data, then
> adding the blacklist to prelink is reasonable. If it is merely that the
> strip binary is doing something wrong, then a BZ against strip is needed
> to get it fixed.

Apparently it's because it appends bytecode to its own binary (which
is a broken thing to do, but is now deprecated anyway[1]).  Strip on
the other hand ought to recognise that the binary is no longer a
coherent ELF file and quit.  So I'd agree this is really a bug against
strip.

Note that we found that strip also destroys MinGW (Windows) binaries.
Again, it should give up on binaries that it doesn't understand,
rather than destroying them.

But is it /usr/bin/strip?  Does prelink run /usr/bin/strip first?  Do
prelink and strip use a common ELF-manipulation library which is at
fault?

Really, cronjobs shouldn't be modifying files in /usr/bin.  Save data
in /var/, or modify the ELF format to make it more efficient so it
doesn't need prelink.

Rich.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900#49

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top