Linux: Dynamic vs Static Linking

Today, we had a chat with a colleague about whether a C/C++ binary (ELF) built on one Linux distribution would work on another. After some research, I found that default GCC builds are dynamically linked, and the ELF file contains:

1. Your program's code
2. A list of dynamic dependencies (shared libraries) it needs
3. Symbols that need to be resolved at runtime

However, it does not contain the actual shared libraries - those need to be present on the system where you run the program. You can see these dependencies using ldd. For example, a simple C "hello world" program with only a printf() call can be built with gcc hello.c -o hello. ldd hello output:

linux-vdso.so.1 (0x00007fff6a0e1000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdaf6400000)

/lib64/ld-linux-x86-64.so.2 (0x00007fdaf66b3000)

The files size is 15960 bytes. To make is truly independent of any shared library we would build it with gcc -static hello.c -o hello_static. ldd hello_static shows:

not a dynamic executable

The size of hello_static is a whopping 900344 bytes, 56X more than the dynamically linked build.

The good news is that these libraries are present by default on virtually every Linux distribution, so including them in every executable would waste a lot of space. However, you must ensure that C++ version (C++17, C++20, etc.) specific features used in your code are supported by the gcc/g++ version on the target Linux distribution. Of course, the CPU architecture has to be the same too — that goes without saying.

On Windows, C++ libraries come with Visual C++ Redistributable:

Note that  if a Windows PC can successfully load and run a DLL compiled with a specific C++ version, it can also run an EXE compiled with that C++ version because the C++ runtime requirements are the same whether the code is in a DLL or EXE. The only difference is how the code is packaged and loaded, not its runtime requirements.

Music: André Rieu & Mirusia - Ave Maria

C++ std::endl vs "\n"

I have a thread safe print function that uses lock_guard and std::cout and is called from different threads. When I replaced std::endl expressions with "\n", my program stopped printing to console. The main difference is that std::endl does two things: it inserts a newline character AND flushes the output buffer, while "\n" only inserts a newline character. In a multithreaded environment, without flushing, the output might stay in the buffer and not be visible immediately.

Memory Insights from a Segfault

Recently, a program crashed with segmentation fault (sigsegv). Since segmentation faults can happen for a variety of reasons, it took some time to find out that the root cause was insufficient stack (stack overflow) due to a function allocating extra 16kB for a local variable, float var[4096]. The quick fix was to increase the stack size of the thread calling that function from 32kB to 1MB. 

Another solution is to move var to static storage instead of using the stack by changing the definition to static float var[4096]. Upon closer inspection of the code, I saw that var was just used to copy a static array before sending it to another function. Since that function was not modifying the array, there was no reason for the copy. Removing var removed large stack allocation. 

Problems like this are stressful in the short term but provide an opportunity to review the concept of memory regions. Here's a concise breakdown:

Static Storage

- Memory allocated at program start, lives for entire program duration

- Size must be known at compile time 

- Good for: fixed-size buffers that exist for whole program 

- Example: static uint8_t buffer[1024];

- Zero runtime allocation overhead 

- Can't be resized 

Stack

- Memory allocated/deallocated automatically when entering/leaving scope 

- Very fast allocation/deallocation - Limited size (often few MB) 

- Good for: small-to-medium temporary buffers 

- Example: void foo() { uint8_t temp[1024]; }

- Risk of stack overflow with large allocations

Heap 

- Dynamic runtime allocation 

- More flexible but slower than stack 

- Larger size available 

- Good for: large buffers or unknown sizes 

- Example: auto* buffer = new uint8_t[1024];

- Risk of fragmentation 

- Must manually manage memory 

For embedded systems with fixed-size allocation needs: 

1. Use static storage for long-lived, known-size buffers 

2. Use stack for small temporary buffers 

3. Consider static memory pools instead of raw heap allocation if you need dynamic allocation

In Visual Studio 2022, you can use Build > Run Code Analysis to detect functions with large stack allocations, they will be marked with C6262 excessive stack usage warnings.