❄️🦊 is a user on octodon.social. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.
❄️🦊 @icefox

Linkers are such weird pieces of software.

So intricate that they're a huge endeavor, so fundamental every developer needs one, but so obscure there's very few of them. There's more production-quality assemblers and web servers than linkers, but neither will ever work without a linker.

Such a strange corner of computer technology.

· Web · 11 · 18

@icefox at least there's more than one FOSS one now!

@er1n @icefox I think I was thinking of the first and third ones, yeah

@er1n @impiaaa yeah basically.

Microsoft link.exe deserves mention because it's apparently actually pretty good.

But even then... Intel has icc, but is there an Intel linker? Not that I'm aware.

Does Solaris have it's own linker? BSDs? Not afaik.

@icefox @er1n @impiaaa Eeeeh, yes?

Solaris has it's own linker, FreeBSD has rtld(1), which itself seems to have diverged significantly from OpenBSD's ld.so(1)

@impiaaa @er1n @icefox I mean, 4.2BSD was a thing before the GNU project released its toolchain, so of course it had to have its own runtime linker.

@kellerfuchs @impiaaa @er1n yeah, but do modern BSDs use it? Idk. I should use bsd more.

@icefox @er1n @impiaaa Nevermind, I'm too tired to speak about tech tonight: you are talking about the toolchain's linker, not the dynamic (“run-time”) linker.

@kellerfuchs @er1n @impiaaa they're intimately but arcanely related!

@icefox @er1n @impiaaa Yes they are, but we kinda settled on the API between the two (ELF) last millenium.

@impiaaa @er1n @kellerfuchs eventually we'll invent something Better Enough that people start using it

But having written an ELF loader, apparently not yet.

@kellerfuchs @er1n @impiaaa I assume PE is is about as good, give or take a little.

Though I still love that a.out's Magic Number is the PDP-8 instructon for "jump forward the length of the header". Beautiful and terrible at the same time, sorta like Galadriel.

@icefox @er1n @impiaaa I believe Solaris (and illumos) has their own linker to go with their own libc. BSDs tend to use the GNU or LLD linkers. Not sure if OS X uses a proprietary linker or a GNU / LLD one.

@impiaaa @samis @er1n Yeah that's the thing

the modern choices are 'gnu' or 'lld', and as far as I know that's literally it.

Anyone nerdy enough writes their own compiler. Lots of people have written their own compressor or archiver; it's still an area of active research.

But linkers? It's kinda a solved problem, and so uninteresting (?). But it's a very large and fiddly problem, and so hard to toy around casually.

Heck, there's way, way more people writing their own *operating system* than their own linker. Or C compiler. Or basically anything you can think of.

@icefox I don't think this is actually true Link time optimization is relatively recent and something the LLVM people have been working on.

And a lot of the limitations of C++ come from it having to be compatible with the C linker. I think things like Rust and Haskell, say, implicitly have their own linker but also use the standard system linker to link with C libraries for foreign calls.

@Azure Rust uses the system linker. Using llvm's code generation to do link-time code optimization (equivalent to what the Java/Clojure people call tree shaking?) is still an unstable feature.

I know this because Windows link.exe does this automatically and someone euphoniously titled WindowsBunny likes to brag about it.

@icefox Tree shaking just gets rid of everything that isn't used. Lisp systems do it when distributing standalone executables. Stalin uses it as a prequel to partially specializing the heck out of everything.

Link time optimization is (or should be) way more than just a tree shake.

@Azure a combination of tree shake, inlining and then optimization based on the IR resulting of the inlining? I am fuzzy on the details.

@Azure Iirc most C compilers stop at function-level tree shake, which is Often Good Enough for technology to mostly stop there since the late 90s.

@Azure @icefox I assume most/all languages that compile to a not-C ABI have their own linker (and use the system's for FFI).

I can at least confirm OCaml and Haskell do, and I'm not sufficiently familiar with other such languages to say.

@kellerfuchs @Azure iirc the thing is that some languages don't have an idea of "linker" as a separate thing. Ocaml is like this too, a think? The compiler combines things itself and there's no "separately compiled but still part of the same program" stage. The combination happens at the AST/IR level, not the object file level.

Not sure if this is correct. I think it's how Rust's link time optimization works though.

@icefox @Azure No, OCaml does go from source files to cm{a,o,xa,xs} (compiled object & library files) and cmi (compiled API description), and then links them into ELF executables.

It just so happens that the compiler and linker are the same program (or rather, the byte-code compiler and linker are se same, and so are the native code versions)

ocaml.org/learn/tutorials/file

@kellerfuchs @Azure I need to code more ocaml then, I guess.

It got sorta eclipsed by C#, then F#, now Rust.

@icefox @Azure You don't have to, it's just sort of like F#, without the training wheels. *runs off before you can pounce.*

More seriously, not interested in language evangelism currently.

@kellerfuchs @Azure *pounces!*

Language evangelism simultaneously the most boring and most enthralling topic ever. Fortunately, I don't need to pursue it right now.

@Azure @kellerfuchs Honestly I think formal methods are The Future, I think we just have a generation or two more of stuff to learn before The Future arrives.

Hopefully I'm wrong! Even if it will mean inconveniently learning a whole new field.

@hannesm That paper is *dynamite*, thank you!

Amazing that it's the first of its kind.

@icefox a pleasure... and it doesn't even handle the dynamic linker iirc