Ada中Binding与Linking的核心差异及相关流程问询

Hey Bogdan, great question—this is a super common point of confusion with Ada's build pipeline, since it adds a step you don't see in languages like C or Python. Let's break this down clearly!

First, let's anchor the core purpose of each step, since that's where the biggest differences lie:

Binding (Ada-Specific Step) #

Binding is unique to Ada and exists to protect Ada's strict type safety and runtime guarantees. Its core job is to:

• Validate that Ada code interacts correctly with external code (like C libraries) via pragma Import declarations—ensuring parameter types, calling conventions, and return values all match up.
• Set up Ada's runtime environment: this includes initializing exception handling, task scheduling (if you're using Ada's tasking features), and standard library utilities.
• Resolve dependencies between Ada compilation units and the Ada Runtime Library (RTL), making sure all required runtime components are included.

Linking (Universal Compilation Step) #

Linking is a step you'll find in almost every compiled language. Its sole focus is on binary-level integration:

• Combine compiled object files (.o/.obj), static libraries (.a), and dynamic libraries (.so/.dll) into a single executable or shared library.
• Resolve symbol references—meaning it connects calls to functions/variables in one file to their actual definitions in another.
• It doesn't care about language-specific rules (like Ada's type safety); it just handles raw binary addresses and symbols.

Let's break down what goes into binding and what comes out:

Inputs #

• Compiled Ada object files (.o/.obj) for every unit in your project (specs and bodies).
• The Ada Runtime Library (RTL) files: pre-compiled binaries that provide Ada's standard library, tasking support, exception handling, and other core runtime logic.
• External library files (e.g., C .a/.so libraries) plus their corresponding Ada binding declarations (via pragma Import or auto-generated binding specs).
• Project configuration (like GNAT's .gpr files) that specifies runtime options (e.g., tasking vs. non-tasking runtime) and compilation flags.

Outputs #

• A special intermediate object file (e.g., GNAT generates b~main.o for a main unit named main.adb). This file contains Ada's runtime initialization code, task startup logic, and all validated binding metadata.
• A dependency list or link script that tells the linker exactly which libraries and object files need to be included to build the final executable.

Your hunch is 100% correct—binding must run before linking. Here's why:

1. The linker needs the intermediate binding object file to properly initialize Ada's runtime. Without it, the executable would crash immediately when trying to use Ada-specific features like exceptions or tasks.
2. Binding catches type mismatches and interface errors early. If your Ada binding for a C function has the wrong parameter type, binding will throw an error—whereas linking would only complain about missing symbols, not type issues.
3. Binding curates all the dependencies the linker needs. It ensures the linker knows to include the correct Ada RTL components and external libraries, so you don't have to manually track every dependency.

As a concrete example, when you use GNAT (the most popular Ada compiler) with gnatmake main.adb, the underlying steps are:

1. Compile all Ada units to .o files.
2. Run gnatbind (the binding tool) to generate a binding unit, then compile that to b~main.o.
3. Run gnatlink (the linking tool) to combine all .o files, the Ada RTL, and any external libraries into the final executable.

内容的提问来源于stack exchange，提问作者user3523954