How LibreOffice Uses Git Submodules and Tarballs

The LibreOffice build system relies on a hybrid dependency management strategy to handle its massive codebase and hundreds of external libraries. It uses Git submodules for closely tied, modular assets like translations, dictionaries, and help files, while relying on pre-packaged external tarballs for third-party software dependencies. This dual approach keeps the core Git repository lightweight, simplifies cross-platform compilation, and gives developers fine-grained control over whether to build internal dependencies from source or link against host system packages.

Git Submodules in LibreOffice

LibreOffice isolates large, semi-independent assets from the main core repository by organizing them into Git submodules. The most common submodules include:

• dictionaries: Bundles of spell-checking, hyphenation, and thesaurus files.
• help: The local help content and documentation system.
• translations: Localization and language packs for global releases.

By offloading these modules, the main repository size is significantly reduced, accelerating initial clones and Git operations. The build system manages these submodules automatically via repository scripts (such as ./g), or developers can initialize them using standard git submodule update --init commands. Developers working exclusively on core engine features can omit submodules entirely during configuration to speed up build and fetch times.

External Tarballs for Third-Party Dependencies

LibreOffice relies on dozens of third-party libraries—such as ICU, Boost, HarfBuzz, and Cairo—to provide core functionality without reinventing existing tools. Rather than vendoring the entire Git histories of these libraries into the source tree, the build system references upstream source tarballs.

1. The download.lst Manifest: Dependency metadata is centralized inside the download.lst file. Each external dependency entry defines the package name, upstream version, source archive filename, and cryptographic hash (SHA256) to ensure integrity and security.
2. Automated Fetching: When running make (or the dedicated make fetch target), the build system parses download.lst and downloads missing archives from official LibreOffice mirrors into a local cache directory (typically tarballs/). If a tarball with a matching checksum already exists locally, the download step is skipped.
3. Unpacking and Patching: During compilation, the build infrastructure in the external/ directory uncompresses the tarballs into temporary work directories, applies LibreOffice-specific bug fixes or compatibility patches, and builds the library using either its native build system (such as CMake or Autotools) or a custom internal Makefile wrapper.

System vs. Bundled Libraries

The external tarball mechanism provides flexibility through configuration flags passed to ./autogen.sh.

• Bundled Builds (--without-system-*): By default (especially on Windows and macOS), the build system compiles the downloaded tarballs directly to create a self-contained, reproducible environment with guaranteed dependency versions.
• System Builds (--with-system-*): Linux distribution maintainers can instruct LibreOffice to ignore external tarballs and link against existing system-installed shared libraries, preventing duplicate code and adhering to distribution packaging policies.