Re: else ladders practice

On 25/11/2024 10:30, Michael S wrote:

On Sun, 24 Nov 2024 13:45:55 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
 

Bart <bc@freeuk.com> writes:

On 24/11/2024 20:01, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:
[...]

Most of a gcc installation is hundreds of header and archive (.a)
files for various libraries. There might be 32-bit and 64-bit
versions. I understand that. But it also makes it hard to isolate
the core compiler.

[...]
That doesn't agree with my observations.
Of course most of the headers and libraries are not part of gcc
itself.
As usual, you refer to the entire implementation as "gcc".
I've built gcc 14.2.0 and glibc 2.40 from source on Ubuntu 22.04.5,
installing each into a new directory.
The gcc installation is about 5.6 GB, reduced to about 1.9 GB if I
strip
the executables.

>
That's even huger than mine! So, that are those 3.7GB full of? What
does the 1.9GB of executables do?

>
I installed compilers for multiple languages.  A more typical
installation likely won't include compilers for Ada, Go, Fortran,
Modula-2, and Rust.  There are a number of hard links to other files;
for example c++, g++, x86_64-pc-linux-gnu-c++, and
x86_64-pc-linux-gnu-g++ are all the same file.  Apparently `du` is
clever enough to count them only once.
>
Here's the output of `ls -s` on the bin directory (sizes are in units
of 1024 bytes) :
>
total 611908
   8828 c++           8960 gm2          8828 x86_64-pc-linux-gnu-c++
   8820 cpp           8264 gnat         8828 x86_64-pc-linux-gnu-g++
   8828 g++          13092 gnatbind     8820 x86_64-pc-linux-gnu-gcc
   8820 gcc           9556 gnatchop     8820
x86_64-pc-linux-gnu-gcc-14.2.0 156 gcc-ar       12564 gnatclean
156 x86_64-pc-linux-gnu-gcc-ar 156 gcc-nm        7864 gnatkr
156 x86_64-pc-linux-gnu-gcc-nm 152 gcc-ranlib    8564 gnatlink
152 x86_64-pc-linux-gnu-gcc-ranlib 8828 gccgo        12764 gnatls
   8828 x86_64-pc-linux-gnu-gccgo 8820 gccrs        13584 gnatmake
8820 x86_64-pc-linux-gnu-gccrs 7784 gcov         12236 gnatname
8828 x86_64-pc-linux-gnu-gdc 6324 gcov-dump    12308 gnatprep
8824 x86_64-pc-linux-gnu-gfortran 6468 gcov-tool    11136 go
  8960 x86_64-pc-linux-gnu-gm2 8828 gdc            620 gofmt
   8824 gfortran    308740 lto-dump
>

 67% of bin directory of i386 gcc13 compiler that I compiled from source
on msys2 few months ago is a single huge executive:i386-elf-lto-dump.exe
410,230,002 bytes with symbols, 28,347,904 bytes stripped.
Copying such file is not instant, even on SSD. Certainly takes time
over internet.
 It does not look like I have any use for it, stripped or not. When I
want dump, I use smaller utility, i386-elf-objdump.exe (14,740,647
bytes with symbols, 2,242,048 bytes stripped) that already does more
than I would know to use.
 

LTO object files are vastly different beasts from normal object files, so it does not surprise me that the dump utility is so much bigger.  If you don't use LTO, then presumably you will not need the lto-dump utility.  (It is not a tool I have ever looked at myself.)
When people build gcc themselves, it is not uncommon that they want binaries with symbols for debugging, testing, profiling, objdumping, or whatever - after all, most users use pre-build binaries.  So it is not unreasonable to have at least some symbols with the binaries.  But it seems here that you have built them with full debugging information, not just symbols.  That is only really useful if you intend to run gcc itself under gdb.  Stripping the binaries isn't going to make them any faster (at least, not under Linux - maybe in Windows the whole file is loaded), but it would make copying the files faster.

Arm gcc12 compiler for small emebedded targets (arm-none-eabi-gcc) in
the same msys2 environment that I did not compile from source also
contains arm-none-eabi-lto-dump.exe and it is also the biggest exe by
far, but at least it is stripped and only 23,728,128