Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Sat, 8 Jun 2024 11:14:45 +0100
Organization: A noiseless patient Spider
Lines: 114
Message-ID: <v41aul$2ikfv$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me> <v2sh19$2rle2$2@dont-email.me>
 <87ikz11osy.fsf@nosuchdomain.example.com> <v2v59g$3cr0f$1@dont-email.me>
 <v30l15$3mcj6$1@dont-email.me> <v30lls$3mepf$1@dont-email.me>
 <v30sai$3rilf$1@dont-email.me> <v320am$1km5$1@dont-email.me>
 <v33ggr$e0ph$1@dont-email.me> <v34bne$i85p$1@dont-email.me>
 <v3758s$14hfp$1@raubtier-asyl.eternal-september.org>
 <v38of2$1gsj2$1@dont-email.me> <v39v87$1n7bk$1@dont-email.me>
 <v3du4s$2febh$3@dont-email.me> <v3etlq$2o0sh$1@dont-email.me>
 <v3goqo$36n61$1@dont-email.me> <v3hehi$39s59$1@dont-email.me>
 <v3j5hm$3j4v3$6@dont-email.me> <v3k50b$3rdhi$2@dont-email.me>
 <v3lt74$48om$15@dont-email.me> <v3mu6f$ct28$4@dont-email.me>
 <v3og9d$pgpu$1@dont-email.me> <v3p6hp$sss0$1@dont-email.me>
 <v3r5u9$1au1k$1@dont-email.me> <v3svmh$1k8ck$1@dont-email.me>
 <v3tlp4$1o860$8@dont-email.me> <v3vtou$27sqi$1@dont-email.me>
 <20240607173657.984@kylheku.com> <v40b9s$29vsj$1@dont-email.me>
 <20240607204550.319@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 08 Jun 2024 12:14:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d4d103a5f52de5a45e686d3a08483f92";
	logging-data="2707967"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19QGIMzHiJIKf59LVQy6Ena"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:GQwL7elVvK/1lWFxr++6T+zGCiQ=
In-Reply-To: <20240607204550.319@kylheku.com>
Content-Language: en-GB
Bytes: 6528

On 08/06/2024 04:55, Kaz Kylheku wrote:
> On 2024-06-08, bart <bc@freeuk.com> wrote:
>> On 08/06/2024 01:39, Kaz Kylheku wrote:
>>> On 2024-06-07, bart <bc@freeuk.com> wrote:
>>>> It's you who can't get your head around the idea that someone could be
>>>> away with a 'linker'.
>>>
>>> You can do away with linkers and linking.
>>>
>>> But it's pretty helpful when
>>>
>>> 1. the same library is reused for many programs.
>>
>> You use a shared library.
> 
> That's linking.
> 
> Static linking is the same thing as dynamic except it's being
> precomputed: the libs are dynamically processed, but then rather
> than the program being run, its image is dumped into an executable.
> That executable no then longer needs to repeat that library processing
> when started; everything is integrated. (There are ways to optimize
> linking so not all the material must be present in memory all at once
> as I describe it above.)

The actual process of linking is a fairly trivial matter, as I showed in 
my 0.8Kloc C program which not only loads and relocates an executable 
file (in my format), but loads, relocates and does symbol fixups of any 
dynamic libraries. (Plus fixes up DLL dependencies too! But the 
relocation of those is done within OS routines at my request.)

What is different in formats like PE and ELF is their tremendous 
complexity; my formats are considerably simpler.

What I mean by 'doing anyway with linkers and linking' is removing the 
need to run a discrete program that might be called 'ld' or 'link' or 
indirectly via 'gcc', from a language implementation.

Primarily by using whole-program compilation, where any inter-module 
references are sorted out early on within the compiler via the global 
symbol table. The compiler directly generates EXE/DLL from source files.

For C, the language requires independent compilation. Here, I generate 
ASM files. But while traditionally those are assembled to object files 
and linked, I use a special assembler where ASM files are directly 
turned into EXE or DLL files.

The linking process is again done by manipulating a global symbol table. 
There are no object files, and no separate discrete link step.

>>> 2. you're selling a library, and would like to ship a binary image of
>>> that library.
>>
>> You ship a shared library.
> 
> No, not always. There is such thing as selling static libraries.
> 
> Numerical code, crypto, codecs.
> 
> A few times in my career I worked with purchased static libs.

If you obtain a static library in the form of an object file or archive, 
then yes you will need a program that can process that file and combine 
it with the rest of your application: a linker.

But if /I/ were to write a linker, even to process PE/OFF files, it 
would be a 50Kloc application. (There is already such a product, not 
mine, which is 47KB, but it has some peculiarities.)


> There are some advantages to it, like that static calls can be
> faster than dynamic,

If you do your own fixups (you generate an executable where DLL 
dependences are resolved via your initialisation code rather than 
getting the OS to do it), you can arrange it so that calls to imported 
routines are direct.

But I don't think it's worth the trouble. You generally know that calls 
across FFI boundaries are going to be a tiny bit slower. That is, by 
needing to execute one extra indirect and probably fully predicted jump 
per call. So usually insignificant.



  and unused parts of static libs can be
> removed at link time.
> 
> Another aspect is that it's possible for static libs to be
> platform-independent, to an extent, because some of the
> object formats like COFF are widely recognized. Whereas
> shared libs tend to be very OS specific. The vendor has to make
> them separately for Windows, Linux, Solaris, BSD, Mac, ...


Windows tends to use PE (which includes COFF). Linux tends to use ELF.

The thing about my private formats (MX/ML) is they would have been 
cross-platform.

> This gruntwork is a pain in the ass that is removed from
> the core value of your code.
> 
> The integrator who buys your static lib can turn it into a
> shared lib for their target system, if they are so inclined.

Sure. My tools can generate OBJ files if necessary. But then it'll be 
somebody else who needs to invoke a linker. Not me.

But if I were to supply a binary, it would be in the form of a DLL. 
There are roundabout ways of bundling it into a EXE if necessary (my ML 
format would be better for such a purpose).