Re: else ladders practice

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

The glibc installation (libraries and headers) is about 199 MB, a small
fraction of the size of the gcc intallation.

>
Is that included in one of those two divisions above?

Of course not.  glibc is not part of gcc.

Of course there are other libraries that can be used with gcc, and they
could take a lot of space -- but they're not part of gcc.

>
So, what /is/ gcc? What's the minimum installation that can compile
hello.c to hello.s for example?

Those are two separate questions.  gcc by itself can't compile hello.c
to hello.s.  But it's always installed along with other tools that allow
it to do so, as part of what the C standard calls an "implementation".

You can't compile hello.c to hello.s without an OS kernel, but I presume
you'd agree that the kernel isn't part of gcc.  And hello.s isn't useful
without an assembler, which is not treated as part of gcc.

gcc is a compiler, or rather a compiler collection.  (The "gcc" command
is the C compiler component of the "gcc" compiler collection.)  Since
gcc does not provide <stdio.h>, I presume that a standalone gcc would
not be able to compile hello.c without depending on a library, whether
that library is installed separately or as part of a package like
tdm-gcc (there's nothing wrong with either approach).

I should also acknowledge that the "gcc" package, whether it's provided
as source code or as binaries, provides some files that are not part of
the compiler itself, for example library files that are closely tied to
the compiler.  Installable software packages don't have to follow any
particular division between compiler, library, and other components.

When I install gcc, binutils, and glibc from the Ubuntu package manager,
the binaries are installed in common directories (/usr/bin, /usr/lib, et
al).  There's no "gcc directory" or "glibc directory".  But the system
keeps track of which files were install from which packages.

Perhaps you don't care what is or isn't part of "gcc".  If that's the
case, that's fine, but it would help if you'd stop referring to things
as "gcc" without knowing what that means.  You're using "gcc-tdm"; just
call it that.

I've done that experiment on my TDM version, and the answer appears to
be about 40MB in this directory structure:
>
 Directory of c:\tdm\bin
24/07/2024  10:21         1,926,670 gcc.exe
24/07/2024  10:21         2,279,503 libisl-23.dll
24/07/2024  10:22           164,512 libmpc-3.dll
24/07/2024  10:22           702,852 libmpfr-6.dll
>
 Directory of c:\tdm\libexec\gcc\x86_64-w64-mingw32\14.1.0
24/07/2024  10:24        34,224,654 cc1.exe
>
 Directory of c:\tdm\x86_64-w64-mingw32\include
17/01/2021  17:33               368 stddef.h
27/03/2021  20:07             2,924 stdio.h
>
               7 File(s)     39,301,483 bytes
>
Here I cheated a little and used the minimum std headers from my
compiler, otherwise I could have spent an hour chasing down dozens of
obscure nested headers that gcc's stdio.h likes to make use of.
>
Is /this/ gcc then? Will you agree that it is by no means clear what
'gcc' includes, or what to call the part of a gcc installed bundle
that is not technically gcc?

It's not entirely clear, but it's much clearer than you make it out to
be.

One thing that should be obvious by now is that stdio.h is not part of
"gcc", though it's probably part of "gcc-tdm".  On my system, stddef.h
is provided by libgcc-11-dev, which is closely associated with gcc.  I'm
not entirely sure why gcc-11 and libgcc-11-dev (the Ubuntu binary
packages) are separate -- nor do I have to care, since the package
management system is clever enough to recognize the dependencies and
keep them in sync.

A more useful installation would of course need more standard headers,
an assembler, linker, and whatever .a files are needed to provide the
standard library.

Sure, those are all part of a C implementation, though they're not part
of gcc.

With clang, it is easier: apparently everything needed to do the
above, other than header files, is contained with a 120MB executable
clang.exe.

That may be true for the "clang.exe" on your system.  I'm fairly sure
it's not true for the "/usr/bin/clang" on my system.  Perhaps you
installed some Windows package that provides the clang compiler and
other components of a C implementation, similar to the way gcc-tdm
provides gcc and other components.

However the full 2.8GB llvm/clang installation doesn't provide any
headers, nor a linker. At least it doesn't use the provided 88MB (!)
lld.exe; it expects to work on top of MSVC, which it has never managed
to do.

I suspect others have managed it, but I haven't tried (I don't use
llvm/clang on Windows other than via Cygwin and WSL).  But apparently MS
Visual Studio can be configured to use clang as its compiler.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */