In today’s development world, using multiple programming languages in a single project is quite common. For example, a web application might use Python (Django) for the backend, HTML/CSS for structure and styling, and JavaScript for frontend interactivity. It’s easy to explain this kind of architecture because each language has its own well-defined role in the stack.

But what happens when a project uses C, C++, Objective-C, or even Go — all low-level, compiled languages — together in a single system? Unlike web tech stacks, these languages don’t just "run" in the browser or server. They need to be compiled, assembled, and linked into one final binary file — a process that can be both powerful and complex.

So, how does it actually work?
How can these different languages — each with its own compiler and build process — produce code that ends up in the same final executable?

That’s where tools like GCC (GNU Compiler Collection) come into play.

In this blog, I’ll walk you through:

• How GCC compiles code step-by-step (from .c to executable)

• How different languages can produce compatible outputs like object files (.o)

• And how the linker is responsible for bringing everything together — or messing it up if you’re not careful

Let’s start from the beginning: the four main stages of GCC.

⚙️ How GCC Works: The 4 Stages of Compilation

The magic of converting source code into an actual executable program doesn’t happen in one step — it’s a pipeline of four key stages. Each stage has a specific role and produces an intermediate file. Let’s break it down:

🧼 1. Preprocessing (.i file)

This is the first step.
Here, the GCC preprocessor handles things like:

• Removing comments

• Expanding macros (#define)

• Including all header files (#include)

After preprocessing, your code is turned into a plain, expanded version where all macros and headers are inserted directly into the file. The output is saved as a .i file.

gcc -E file.c -o file.i

🛠️ 2. Compilation (.s file)

Next, the compiler takes the .i file and translates it into assembly code — a low-level, human-readable representation of machine instructions.

This stage focuses on:

• Syntax checking

• Code optimization

• Converting high-level logic into CPU instructions

The output is a .s file (assembly source).

gcc -S file.i -o file.s

⚙️ 3. Assembling (.o file)

The assembler takes the .s file and translates it into machine code, but it’s not yet a complete program.
This file is called an object file, with a .o extension.

At this stage, the code is:

• In binary form

But still missing some parts (like function references from other files or libraries)

gcc -c file.s -o file.o

🔗 4. Linking (Executable)

Finally, the linker steps in.

It takes all the .o files — including those from your code and any external libraries — and combines them into a single, fully functional executable.

This stage:

• Resolves symbol references (e.g., function or variable definitions)

• Connects different files together

• Handles memory layout

The output is your final program, often named a.out by default.

gcc file.o -o my_program

🔗 Dynamic Linking and Shared Libraries

In the previous section, we talked about how the linker combines object files into one final executable. But there’s an important distinction to understand here: static linking vs dynamic linking.

📦 Static Linking (Brief Recap)

In static linking, all the code — including functions from external libraries — is bundled directly into your executable at compile time.

• ✅ No external dependency at runtime

• ❌ Larger executable file size

• ❌ Each program has its own copy of the same library (wastes memory)

⚙️ What is Dynamic Linking?

Dynamic linking solves this by not copying the actual library code into your executable. Instead, your executable contains only references (or "placeholders") that point to shared libraries (usually .so files in Linux) that exist outside the program.

At runtime, the operating system:

• Loads these shared libraries into memory (if not already loaded)

• Links them to your executable while it’s starting up

• Resolves any external symbols (like function calls)

📂 Example: libc

Every C/C++ program uses libc — the standard C library.

• In static linking, the entire library is copied into your binary

• In dynamic linking, your executable just says:
  ➤ “Hey OS, when I run, link me to /lib/libc.so.6 please.”

🧠 How Does It Help?

• ✅ Reduces executable size — your program doesn’t carry the full library code

• ✅ Memory-efficient — multiple programs can use the same library already in memory

• ✅ Easy updates — fixing one .so file updates all programs using it

• ❌ Dependency risk — if the .so file is missing or incompatible, the program may crash

Dynamic linking is one of the main reasons why compiled programs today are much more modular, smaller, and efficient — especially on systems where many programs share the same system libraries.

Next, we’ll explore how different languages (like C, C++, Rust, etc.) generate .o files that the linker can understand — allowing truly mixed-language projects.

🤝 How Different Languages Work Together: Cross-Language Linking

You might wonder: how can a single program be written in C, C++, Rust, and Assembly, and still work as one unified system?

The secret is this:

All these languages eventually compile down to object files (.o) — and the linker doesn't care which language they came from, as long as the format and rules are followed.

🔧 The Common Ground: Object Files (.o)

Regardless of the source language, once the code is compiled, it becomes an object file that:

• Uses a standard format (like ELF in Linux)

• Contains machine code

• Includes metadata like function names, variables, and memory layout

As long as each language’s compiler generates object files that follow the same ABI (Application Binary Interface), they can be linked together into a single executable.

🧩 Real-World Example: C + C++

C++ has features like classes and function overloading that C doesn’t understand. But with extern "C", you can tell the C++ compiler:

“Compile this part as if it’s in C.”

// C++ file
extern "C" {
    void hello_from_c();
}

int main() {
    hello_from_c();
    return 0;
}

// C file
#include <stdio.h>
void hello_from_c() {
    printf("Hello from C!\n");
}

gcc -c hello.c -o hello.o
g++ -c main.cpp -o main.o
g++ main.o hello.o -o output

✅ One final executable, made from both C and C++.

common issues, memory errors, and wrapping up

⚠️ Common Pitfalls in Cross-Language Linking & Memory Management

While combining code from different languages sounds exciting, it often leads to subtle and hard-to-debug issues if you’re not careful. Below are some of the most common problems you might encounter:

❌ 1. Symbol Mismatches

Each compiler may name functions differently in the object files (this is called name mangling). For example:

• C++ mangles names to support function overloading

• C does not

Fix: Use extern "C" in C++ to make symbols C-compatible.

❌ 2. Calling Convention Conflicts

Every language might use a slightly different rule for how:

• Arguments are passed (stack/register)

• Return values are handled

• The stack is cleaned up

Fix: Make sure both sides (caller & callee) use the same calling convention and match the function signature exactly.

❌ 3. Struct Misalignment or Padding

Different compilers (or even the same compiler in different modes) might lay out structs differently in memory.

This can cause:

• Garbage values

• Crashes due to misaligned memory access

Fix: Use fixed-size data types (int32_t, uint8_t) and #pragma pack or alignment attributes when needed.

❌ 4. Memory Ownership Confusion

When one language allocates memory and another frees it, you can get:

• Double free errors

• Memory leaks

• Segmentation faults

Fix: Define a clear contract about who allocates and who frees memory.

🧠 Conclusion

Understanding how GCC works behind the scenes gives you a deeper appreciation for what’s really happening when you hit “compile.”

From preprocessing to linking, each stage plays a critical role in transforming source code into a working program.

And when it comes to using multiple languages in a single project — whether it’s C, C++, Rust, Go, or Assembly — the real challenge isn’t writing the code… it’s making sure the output files can safely work together.

💡 One bad .o file with a wrong assumption about memory, naming, or calling convention can break your entire system.

So next time you’re debugging a strange runtime crash or missing function — look deeper. It might just be your linker trying to tell you something.

Hey there! 👋

Welcome to 0to1 — a space where I share the things I learn, explore, and find interesting as a student.

I started this blog to document my learning journey. I’m not an expert — I’m just someone who enjoys figuring things out and writing them down in a way others (especially beginners) might find helpful. Whether it’s a concept I finally understood, a project I worked on, or just something that caught my attention, I’ll share it here in the simplest way possible.

What to Expect

On this blog, you’ll find posts about:

• Topics I’m learning in computer science and development

• Maths, logic, or even physics ideas that make me think

• Errors I fix, tools I try, and insights I gain along the way

• Anything that helps me grow from knowing nothing to knowing something

This is not a niche blog. It’s just a student’s notebook, shared publicly.

Why “0to1”?

Because every learning journey starts at zero.
And this blog is my way of going from 0 to 1 — one small step at a time.

If you're learning too, struggling to understand new concepts, or just curious like me — I hope you’ll find something relatable here.

Thanks for visiting. More posts coming soon! 🌱