Deutsch   English   Français   Italiano  
<20241125113046.00001e69@yahoo.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Mon, 25 Nov 2024 11:30:46 +0200
Organization: A noiseless patient Spider
Lines: 73
Message-ID: <20241125113046.00001e69@yahoo.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Nov 2024 10:29:58 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1a0f9a6f1d2b7cf84b10117aeb699143";
	logging-data="2439217"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19DW4FRVIiLk6McB+OZdVJbYhLCGW2QiJI="
Cancel-Lock: sha1:SE60uDf8alpnl/B6BcoEyQy3PO0=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 4820

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.

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