Why do we need to call two separate `strip` commands in section 5.35 ("stripping")

davecan · 12-03-2019, 04:36 PM

In section 5.35 (current 9.0 LFS) the first two commands are:

Code:

strip --strip-debug /tools/lib/*
/usr/bin/strip --strip-unneeded /tools/{,s}bin/*

It struck me as odd that it was using the relative path first and absolute path second. So I did a which strip and the relative one is referencing /tools/bin/strip which means it was built during the compilation process. I dug around and discovered it was part of binutils.

My question is, why do we need to run two different commands here? Obviously the /tools/bin/strip is configured in a certain way such that using /usr/bin/strip wouldn't work for the first case.

But what actually happened behind the scenes here that resulted in requiring two different commands, and what is actually different between them?

Thanks.

TheRealGrogan · 12-03-2019, 05:14 PM

Well, stripping static libraries will BREAK them (deleting archive symbols) so you would only want to use --strip-debug to remove debugging symbols on .a files. That's why, because it's using a wildcard for all the files in lib. It's generally safe to use --strip-unneeded on shared libraries (.so) but not static. Stick with --strip-debug for the libraries though, it will remove most of the symbols.

It's safe to strip binaries with --strip-unneeded (stick with that) or even the default of --strip-all in most all cases.

P.S. No, the strip programs will not be configured differently. It's YOU that tells strip how to strip. Strip is strip, but you want to avoid a situation where you are stripping the strip program you are using as it would likely segfault, hence using the other strip binary :-)

TheRealGrogan · 12-03-2019, 05:32 PM

By the way, if anybody accidentally strips static libraries incorrectly, they can be fixed with ranlib which will regenerate the archive header data. They shouldn't need to be recompiled.

davecan · 12-04-2019, 07:40 AM

Thanks. So does that mean that once the second line is run the version of strip in /tools/bin/strip is no longer usable? If not then I'm not quite getting why the /tools/bin/strip is used at all then, since if they both do the exact same thing then using /usr/bin/strip for both commands would seem more straightforward.

TheRealGrogan · 12-04-2019, 12:45 PM

No, it doesn't mean that, just that if you strip a running binary (or libraries that are in use) it's likely to crash. I don't know why they wrote it that way, it really doesn't matter beyond that.

I don't really follow all procedures line by line (I know what I'm doing), I did my own stripping offline (after exiting the chroot) using my own commands with the host system's strip whenever I was stopping for whatever reason. Same program (and same version even, in my case) and it's just reading symbols, making a temporary copy, removing them and replacing the original. That's why you don't do it on running objects.

P.S. If I've just done a "make install" of something on my system, the binaries and libraries aren't loaded yet. I'll enter a directory and

Code:

file * | grep 'not stripped'

That will print a list of everything that's not stripped and I'll use a command to strip only that (maybe with a wildcard if I want to catch multiple similarly named things in one command).

Code:

[grogan@getstuffed:~]$ cd /usr/lib
[grogan@getstuffed:lib]$ file * | grep 'not stripped'
crt1.o:                                                ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), for GNU/Linux 4.19.0, not stripped
crti.o:                                                ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
crtn.o:                                                ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
gcrt1.o:                                               ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), for GNU/Linux 4.19.0, not stripped
libasan_preinit.o:                                     ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped
liblsan_preinit.o:                                     ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped
libmcheck.a:                                           ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
libpython2.7.so.1.0:                                   ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped
libtsan_preinit.o:                                     ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped
Mcrt1.o:                                               ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
Scrt1.o:

Don't touch those compiler objects (*.o) but look there, I had to rebuild my python 2 the other day (needed to remove a macro disabling the sqlite3 extension loader to compile Firefox) and I forgot to strip it. I'm not invoking any python2 commands right now, so it's safe to strip that.

Code:

[root@getstuffed:lib]# strip -p --strip-unneeded libpython2.7.so.1.0
[root@getstuffed:lib]#

(remember, don't use --strip-unneeded on static libraries... not on .a files and --strip-debug is always safer in general)

The -p switch with strip preserves timestamps. I want to keep those, because it makes it easier to find files later.

Another thing, most gnu autotools based builds have a "make install-strip" target. I try that first, to strip things as they are installed. If the command fails with no such target install-strip, then it's "make install" and manual stripping.

davecan · 12-04-2019, 02:13 PM

Useful info thank you.

pan64 · 12-04-2019, 02:21 PM

just a comment: you do not need to strip anything, they will work without that, just occupy more disk space. Strip is "only" used to remove some symbols from the binary.
(But actually these [some] symbols required in libraries to be able to use them).

TheRealGrogan · 12-04-2019, 03:19 PM

Yes, but taking more space on disk means more gyrations (seeking) to find what it needs to load at runtime. I'd agree that static libraries don't matter, but I want binaries and shared libraries stripped.

It can actually be quite significant if something is compiled with -g, as much as 10 times the size in some cases I've noticed. For example:

Code:

[grogan@getstuffed:dri]$ pwd
/usr/X11R7/lib/dri
[grogan@getstuffed:dri]$ ls -l r300_dri.so
-rwxr-xr-x 8 root root 19341472 Nov 25 05:49 r300_dri.so

Those files in there were 150 Mb+ each before stripping.

P.S. Mechanical storage here.

pan64 · 12-05-2019, 02:01 AM

Hm. Linux is able to read only parts (blocks), no need to put the whole executable into RAM, therefore that debug info is probably not read at all. It is not that trivial.
Anyway, I wanted only say: without stripping everything will work without problems.

TheRealGrogan · 12-05-2019, 06:26 AM

I didn't mean that, just that more crap on disk generally means more seeking. Yes, of course binaries and libraries will work if not stripped (it says so right there in the book, too), otherwise how could you even have symbols? What's not trivial is just how much larger debugging symbols can make the objects.

When done, I tar my results up from off system (tar czfp to preserve), format and tar it back again to write a more optimized access pattern after all that make installing and stripping. That makes a difference on mechanical storage.