[comex]

It is viable against the IR that static libraries contain when LTO is enabled.

LTO essentially means “load the entire compiler backend into the linker and do half of the compilation work at link time”.

It’s a great big hack, but it does work.

[ibejoeb]

Right, but I think that's what the question of "Why is the linker too late?" is getting at. With zig libc, the compiler can do it, so you don't need fat objects and all that.

---

expanding: so, this means that you can do cross-boundary optimizations without LTO and with pre-built artifacts. I think.

[DannyBee]

Calling this "properly" is a stretch at best.

I will say first that C libc does this - the functions are inline defined in header files, but this is mainly a pre-LTO artifact.

Otherwise it has no particular advantage other than disk space, it's the equivalent of just catting all your source files together and compiling that. If you thikn it's better to do in the frontend, cool, you could make it so all the code gets seen by the frontend by fake compiling all the stuff, writing the original source to an object file special section, and then make the linker really call the frontend with all those special sections.

You can even do it without the linker if you want.

Now you have all the code in the frontend if that's what you want (I have no idea why you'd want this).

It has the disadvantage that it's the equivalent of this, without choice.

If you look far enough back, lots of C/C++ projects used to do this kind of thing when they needed performance in the days before LTO, or they just shoved the function definitions in header files, but stopped because it has a huge forced memory and compilation speed footprint.

Then we moved to precompiled headers to fix the latter, then LTO to fix the former and the latter.

Everything old is new again.

In the end, you are also much better off improving the ability to take lots of random object files with IR and make it optimize well than trying to ensure that all possible source code will be present to the frontend for a single compile. Lots of languages and compilers went down this path and it just doesn't work in practice for real users.

So doing stuff in the linker (and it's not really the linker, the linker is just calling the compiler with the code, whether that compiler is a library or a separate executable) is not a hack, it's the best compilation strategy you can realistically use, because the latter is essentially a dream land where nobody has third party libraries they link or subprojects that are libraries or multiple compilation processes and ....

Zig always seems to do this thing in blog posts and elsewhere where they add these remarks that often imply there is only one true way of doing it right and they are doing it. It often comes off as immature and honestly a turnoff from wanting to use it for real.

[pjmlp]

Yeah, like their solutions to detecting use after free are hardly any different from using something like PurifyPlus.

[gary_0]

As I understand it, compiling each source file separately and linking together the result was historically kind of a hack too, or at least a compromise, because early unix machines didn't have enough memory to compile the whole program at once (or even just hold multiple source files in memory at a time). Although later on, doing it this way did allow for faster recompilation because you didn't need to re-ingest source files that hadn't been changed (although this stopped being true for template-heavy C++ code).

[account42]

It's hardly a hack when its how most languages work in the first place.