Saving some MB of Disk-Space and Seconds of Loading Time using "STRIP"

[deringenieur71]

Hi,

just learned about the nice space-safing command STRIP on linux.

I suggest implementing it into the standard build processes of CPCTELERA to have less impact on disc space and loading time. We come from a small machine and should always think about that.

I.E. this should "strip" all your EXE-Files if you have a cygwin CPCTELERA

find . -name "*.exe" -print0 | xargs -0 strip

[dfreniche]

Hi @deringenieur71. I don't quite understand this thread. strip removes not used information from your binary files, for instance, if you're building for 64bit and 32bit you can strip out all 64 code if running in a 32bit machine. But stripping out .exe files in a Linux machine, results in...? A better x86_64 binary?

If we're producing a release build, all debugging symbols shouldn't be there. So strip would only be useful if using "fat" binaries. Still can't understand how the use of strip would be beneficial here. Sorry, can you clarify this point?

Info on strip from Wikipedia

We also have strip on macOS, just FYI.

[deringenieur71]

Ah okay, maybe my post was to short of information.

I just recognized this option (now you know I come from Z80 and WIN32) and experimented with my local build cygwin64 copy of cpctelera. The *.EXE's in there (\tools) where significant smaller after my experiment. So I thought adding the "-s" option to the GCC command while building the tools would help on all platforms.

Like in "# Makefile for 2cdt utility" https://github.com/lronaldo/cpctelera/blob/master/cpctelera/tools/2cdt/Makefile

$(OBJ)/%.o: $(SRC)/%.c
$(CC) $(CFLAGS) $< -c -o -s $@

instead of

$(OBJ)/%.o: $(SRC)/%.c
$(CC) $(CFLAGS) $< -c -o $@

On the other hand it just may be that my built version of the tools was corrupt somehow and all *.EXE should have been stripped automatically by build process of cpctelera which just went wrong on cygwin64 win 10.

[lronaldo]

Adding -s to GCC by default does not seem a sensible option for all uses of CPCtelera. That would remove symbol tables and relocation information from executables, making them usesless if you try to execute them under an ASLR OS. There are also other cases in which removing relocation information may result in execution problems. These risks could ruin the experience for some users.

I think this could be discussed if CPCtelera executables were a problem due to their size. However, I assume that is not the case. Then, the sensible option from my point of view is leave this up to the user. If users want to do so, they can at their own risk. Source code is provided, so users can do this if they wanted.

On the other hand, all executables are created with no debug information, so stripping them should not have an effective impact on result, as no debugging symbols are included.