On 3/29/19 12:23 PM, Tom Hughes wrote:
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.
Thanks for the answer, but I don't see ls failing to load if I run
--strip-all. ls is reported to be a PIE executable.
From my original email, ls is still reduced when --strip-unneeded is used:
161896 ls (from Fedora RPM)
150008 ls-full (after strip)
150008 ls-unneeded (after strip --strip-unneeded)
brp-strip is removing only debugging symbols for non "ELF 64-bit LSB
shared object", shouldn't it be doing --strip-unneeded for those? or for
all executables?
"strip -g ls" removes debugging symbols for ls, that is what brp-strip
does but it doesn't apply to ls because it is filtered with the "grep -v
' shared object,'" inside the script.
Tom
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
