Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Mon, 25 Nov 2024 11:35:20 +0000
Organization: A noiseless patient Spider
Lines: 113
Message-ID: <vi1ndo$2of44$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>
 <vi0enr$2el9e$1@dont-email.me> <87o724m288.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Nov 2024 12:35:20 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c80a36c81a7479915291e305ba49d1d4";
	logging-data="2899076"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+/BVm+dlDCieqO6aFnhcAs"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:lZL6FBosn1IY0C3LfJZ/YUhjKvk=
In-Reply-To: <87o724m288.fsf@nosuchdomain.example.com>
Content-Language: en-GB
Bytes: 6129

On 25/11/2024 03:17, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 24/11/2024 21:45, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
> [...]
>>>> 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.
>>
>> This seems to be a thing with Linux, where a big chunk of a C
>> implementation is provided by the OS.
> 
> I'm not sure what you mean by "provided by the OS".  Linux-based
> systems tend to be very modular, with almost everything provided by
> some installable binary package.  Some of those packages have to
> be provided by default, for example any dynamic libraries relied
> on by most executables.  Files that are needed for development,
> such as header files, compilers, and associated tools such as
> assemblers and linkers, may be optional.


Well, does a C compiler for Linux come with its own stdio.h, or does it 
share /usr/include/stdio.h along with other compilers?

C compilers for Windows tend to be self-contained. Except for clang (see 
below). So each has its own stdio.h.

The only thing the OS provides is msvcrt.dll, a library of C standard 
functions, one which probably started out for internal use but too many 
programs now rely on it.


> 
>> That is, standard headers, libraries, possibly even 'as' and 'ld'
>> utilities.
> 
> On my system (Ubuntu), the as and ld commands are provided by the
> binutils package ("binutils-x86-64-linux-gnu").  Some distributions
> may install these by default.  Others do not, but they're easy
> to install.
> 
>>             On Windows, C compilers tend to be self-contained (except
>> for Clang which appears to be parasitical: it used to piggy-back onto
>> gcc, then it switched to MSVC).
> 
> I don't know what you mean by "piggy-back onto gcc".

It relies for things like header files, linkers and libraries on an 
existing gcc installation.

I used clang for 18 months before I realised this.

Then they changed over to relying on MSVC for those facilities. This is 
when it started having trouble finding and syncing to MSVC, even when I 
had a working CL compiler.

> 
>> I'm not sure what the utility to compile C programs is called, if it
>> is not 'gcc'. But this is a C group, I would expect people to know it
>> is a C compiler, or the front end of one.
>>
>> However I use 'gcc' in other forums and everyone knows what I mean.
>>
>> What do /you/ call the C compiler that is invoked by gcc?
> 
> I call it gcc.
> 
> "gcc" is the name for several things.  It's the "GNU Compiler
> Collection".  It's the command invoked as the driver for any of
> several compilers that are part of the GNU Compiler Collection.
> It can refer specifically to the C compiler.  It's mildly confusing
> for historical reasons, but most people don't have much of a
> problem with it, and don't pretend that it's more confusing than
> it really is.

But you seem to like pointing out that gcc doesn't include header files, 
assemblers, linkers and libraries. And previously you claimed that:

  "gcc by itself can't compile hello.c to hello.s."

So, what does it need? Is your point that it invokes a separate program 
like 'cc1.exe'? (Plus those 3 other binaries I listed in the case of tdm.)

You also said:

"You can't compile hello.c to hello.s without an OS kernel"

I guess you mean that it needs on OS to provide a file system, means to 
launch an executable like gcc.exe in the first place, and a display for 
messages?

That's a rather silly one. (However my first compiler did run on bare 
metal!)

 >>And hello.s isn't useful without an assembler, which is not treated 
as part of gcc

I deliberately stopped at the assembly file because I knew you would 
leap at that.

I assume that turning a .c file into .s/.asm is the very definition of 
what a baseline C compiler is expected to do.

It seems you are still disputing this and casting confusing. C compilers 
for Windows such as lccwin32, Pelles C, DMC, tcc, my mcc/cc are all 
self-contained and can turn hello.c all the way to hello.exe.

It is gcc that is always the exception, in every way (like generating 
a.exe files by default, or thinking that HELLO.C must be a C++ file).