Why do we need to call two separate `strip` commands in section 5.35 ("stripping")
In section 5.35 (current 9.0 LFS) the first two commands are:
Code:
strip --strip-debug /tools/lib/* 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. |
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 :-) |
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.
|
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.
|
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' Code:
[grogan@getstuffed:~]$ cd /usr/lib Code:
[root@getstuffed:lib]# strip -p --strip-unneeded libpython2.7.so.1.0 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. |
Useful info thank you.
|
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). |
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 P.S. Mechanical storage here. |
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. |
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. |
All times are GMT -5. The time now is 01:04 AM. |