On 29/03/2019 16:17, Robert Marcano wrote: > I have been working on a private RPM for a Rust based program and > noticed that the RPM strip scripts are not reducing the binaries files > like when I execute strip directly on those binaries. > > The first thing I checked is the brp-strip script. This one is > filtering executables where "file" reports it is a "shared object", > Rust binaries are marked as "ELF 64-bit LSB shared object" instead of > "ELF 64-bit LSB executable". My understating of this after a few web > searches is that this is for security features like PIE and ASLR. > > brp-strip-shared runs "strip --strip-unneeded" but brp-strip run > "strip" (no arguments). Is there a reason why binaries marked as "ELF > 64-bit LSB shared object" should not be fully stripped? Yes - read the manual page definition of --strip-unneeded and you will see:   "Remove all symbols that are not needed for relocation processing." So the extra bits it leaves (which --strip removes) are the symbols needed to be able to relocate it, and shared libraries and position independent executables need to be relocated when they are loaded. In short if you use --strip you will find that you are no longer able to actually load the program or shared library.

Tom

On 3/29/19 9:17 AM, Robert Marcano wrote: > I have been working on a private RPM for a Rust based program Side note on this -- if you do package Rust shared libraries, not just executables, and you want them to be available for further linking, then rustc needs to have the metadata in the .rustc section. In rust.spec, I had to explicitly preserve this: %global _find_debuginfo_opts --keep-section .rustc (This is assuming you also side-step the Rust ABI question by keeping a consistent rustc version for all your shared library use.)