Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Mon, 25 Nov 2024 13:45:28 +0100
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <vi1rh9$2p5ve$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vhgr1v$2ovnd$1@paganini.bofh.team> <vhic66$1thk0$1@dont-email.me>
 <vhins8$1vuvp$1@dont-email.me> <vhj7nc$2svjh$1@paganini.bofh.team>
 <vhje8l$2412p$1@dont-email.me> <WGl%O.42744$LlWc.33050@fx42.iad>
 <vhkr9e$4bje$1@dont-email.me> <vhptmn$3mlgf$1@paganini.bofh.team>
 <vhq6b4$17hkq$1@dont-email.me> <vhqm3l$3ntp7$1@paganini.bofh.team>
 <vhso61$1o2of$1@dont-email.me> <vhtrns$71ic$1@paganini.bofh.team>
 <vhtvvc$1ukc7$1@dont-email.me> <vhuc2j$7s5i$1@paganini.bofh.team>
 <vhv5m4$27sco$1@dont-email.me> <87wmgsmme0.fsf@nosuchdomain.example.com>
 <vi03n5$2c7jl$1@dont-email.me> <87sergmhkc.fsf@nosuchdomain.example.com>
 <20241125113046.00001e69@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Nov 2024 13:45:30 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ddbcd30071255d634eae9756000f9ecd";
	logging-data="2922478"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18O5vYqQeEiTxeFIhVqiL+JnzLCcHJQKfA="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:QPQeZnQY1HLEaACVKM5jNSri/Q8=
In-Reply-To: <20241125113046.00001e69@yahoo.com>
Content-Language: en-GB
Bytes: 5962

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
>