Fix internal linker for GCC/LLVM/Clang COFF objects on Windows x86, x86-64

Coldzer0requested to merge
Coldzer0/FPC:main into main

Summary

Fix internal linker to correctly handle COFF object files and AR archives produced by GCC (MinGW) and LLVM/Clang, enabling static linking of C++ libraries on Windows x86-64.

Changes:

  • Skip optional second linker member and parse long filename tables in AR archive reader (owar.pas)
  • Keep .ctors, .dtors, and .text.startup sections so C++ static constructors/destructors survive section removal (ogcoff.pas)
  • Parse COMDAT auxiliary records including selection types and associative section references (ogcoff.pas)
  • Cascade Used flag along associative COMDAT chains so companion sections follow their target (ogbase.pas)
  • Create unique symbols for same-name COMDAT sections to prevent relocations resolving against the wrong section (ogcoff.pas)

System

  • Operating system: Windows (all versions)
  • Processor architecture: x86, x86-64

What is the current bug behavior?

When linking C++ libraries (e.g. ImGui + ImPlot) compiled with LLVM/Clang or GCC/MinGW via FPC's internal linker:

  1. AR archives with long filenames or a second linker member fail to read - linker cannot find object members
  2. C++ static const data initialized via constructors appears as all zeros because .ctors/.dtors sections are removed during the unreferenced section elimination pass
  3. COMDAT auxiliary records are not parsed, so associative sections are silently discarded

What is the behavior after applying this patch?

  1. AR archives from all toolchains are read correctly including long member names and second linker members
  2. C++ static constructors and destructors execute at program startup, properly initializing static const data
  3. Associative COMDAT sections are kept or discarded together with their associated section

Merge request reports