Compiled and interpreted

02Three roles

Follow the build arrow: source is input, the compiler/linker produces an output artifact, and a later run loads that artifact. In gcc -O0 -g -o greet greet.c, gcc is the compiler driver, -O0 requests minimal optimization, -g requests debugging information, -o greet names the output and greet.c is the input. The command shown is an unrun candidate.

ELF means Executable and Linkable Format, used for several kinds of compiled artifacts on Linux. An executable is one possible ELF artifact; an ELF object file is not automatically a runnable program. Architecture identifies the target instruction family, such as x86-64 or ARM. Matching the file format does not guarantee that another machine can run it.

A separately recorded build or run with a different output name or flags cannot supply the missing artifact for this example. The candidate -O0 -g greet and hello executables are absent. No matched disassembly or debugger session is included.

/* Worked C source. Not the question's hello.c. Not compiled. */
int main(void) {
    return 0;
}

# Worked Python source. python3 greet.py printed north desk.
print("north desk")

03Classify the hello card

Apply the worked badge diagram to the different supplied greet.c and greet.py sources. Trace greet.c through the candidate build arrow and identify greet.py as separate script source. Then read the hello rows as independent checkpoint evidence. The question asks about an artifact role without claiming that the missing executable was produced.

/* Question fixture. C source for the stated Linux build. Not compiled. */
int main(void) {
    return 0;
}

# Python source. python3 hello.py printed north desk.
print("north desk")

Build card for the hello fixtures. Not a compiler log. Not a file(1) capture.

Row H-1. hello.c
Role: C source. This text file exists in the lesson download.
The stated build reads it as input.

Row H-2. hello
Role: ELF executable for a stated Linux x86-64 gcc build.
This file was not produced. There is no hash and no file(1) line.
It is the compiler-output role on this card.

Row H-3. hello.py
Role: Python source. The Python 3.12 tutorial describes an interpreter that reads a script from a file.
This file is not the output of the C build.

Unrun candidate command, owned directory only:
gcc -O0 -g -o hello hello.c

Both hello.c and hello.py are supplied source files. No matched hello ELF is supplied. Do not run the candidate for this lesson. An ARM machine is not assumed to run an x86-64 ELF.

1. For the supplied greet.c source, read the candidate gcc -O0 -g -o greet greet.c instruction from the explanation. Identify its input and planned output name.
2. Compare the greet.py text with greet.c. Explain why the Python source is not produced by the C command.
3. Rubric: your note keeps build input, planned product and runtime-read script as separate roles, and labels the planned artifact missing.
4. Read the hello card for the later question, then stop without compiling or running either source.

04Optional challenge

Write two sentences: what a later reader would need besides hello.c to rebuild the same executable, and why the missing ELF means you cannot check that rebuild yet. About ten minutes.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Owned directory inventory: lantern.c and lantern.py only.
Candidate: gcc -O0 -g -o lantern lantern.c
The planned executable role is Linux x86-64 ELF.
No compiler log, executable hash or run exists.
A Python runtime would read lantern.py separately.

06Explain your evidence

Optional written self-check: explain one decision using the supplied case. No tool run is required.

Check your explanation: identify compiler input, proposed output and runtime input; keep file format and machine family separate; label absent build and run evidence explicitly.