3
$\begingroup$

As far as I know, only C, C++, and Objective-C (in most used languages) need a linker when compiling, languages like Java and C# don't have one, and it seems more and more modern languages do not have a linking stage nowadays.

  1. Why?
  2. If there's no linker, the code cannot turn into machine code, so languages without a linker must have a virtual machine to run on(things like JIT still need a vm), right?
  3. Languages can call each other by using abi if both them has a linking stage, right?
|cite|improve this question
$\endgroup$
  • 1
    $\begingroup$ Please ask only one question per post. Among those here, 2) is probably the most fitting here. 1) is subjective and offtopic (ask the language designers), 3) is ill-posed (languages don't call each other, programs do) and probably offtopic. $\endgroup$ – Raphael♦ Feb 21 at 5:26
8
$\begingroup$

You seem confused about what a linker does. It does not produce machine code. It merely sticks together (links, if you will) pieces of machine code that have already been produced by a compiler (typically).

What you were probably thinking of is that a linker produces an executable, or at least that's what a linker like ld does. This was the point of ld: to take pre-compiled libraries (.a files in UNIX parlance) and combine them together with object files to produce executables so you wouldn't need to recompile a library for every program that used it.

That said, there's nothing that keeps a compiler from just outputting an executable directly, but I don't think that this is actually happening that commonly. I'm pretty sure most languages that compile to native code do still have a linking stage. They just don't require you to explicitly call it yourself. In fact, LLVM is a popular backend for modern languages targeting native code, and building a new linker is one of the projects of LLVM. The premise that modern languages, at least those that directly produce native code, don't have a linking stage is incorrect.

For languages that primarily target a VM, they may not use ld, but that doesn't mean they don't have linkers. The recent addition to Java of "modules" has lead to jlink. More fundamentally and historically, the most natural thing to call a linker in Java is the ClassLoader. It even mentions linking the class. This is a dynamic linker. It performs the link stage at runtime. Here's the description of linking from the Java Language Specification. Of course, as always, there's nothing that stops you from compiling Java to a native executable. In that vein, there's also nothing stopping Java bytecode from being machine code.

|cite|improve this answer
$\endgroup$
  • 1
    $\begingroup$ Hi, one more question, suppose we are on a platform which uses ELF, does that mean an object file and an executable file are both in ELF format? Only difference is that object files has missing symbols which need a linker to resolve, and linkers nowadays also turn several resolved object files to a single executable ELF file? $\endgroup$ – reavenisadesk Feb 21 at 8:54
  • 1
    $\begingroup$ An executable can have unresolved symbols because dynamic linking is a thing, so a symbol could be resolved at runtime. If the OS expects ELF executables, then the executables will need to be ELF. The linker, however, can do whatever it wants to produce those ELF files. It doesn't need to consume ELF object files. As a practical matter it probably will so that it can fit nicely into the existing toolchain. $\endgroup$ – Derek Elkins Feb 21 at 23:37
  • 1
    $\begingroup$ @reavenisadesk I recommend looking into how an image-based system such as Squeak Smalltalk works to get a feel for how radically different the design decisions can be for these topics. $\endgroup$ – Derek Elkins Feb 21 at 23:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.