libxml2 ships three build systems, dozens of optional modules, and a warning about untrusted XML

The GitHub repository is a mirror, not the source of truth

This repository is described as a read-only mirror of the project at gitlab.gnome.org. The README states plainly that the git repository is hosted on GNOME's GitLab server, and that official releases can be downloaded from download.gnome.org. Bugs go to the GitLab issue tracker, documentation lives in the GitLab wikis, and contributions are made through issues and merge requests on GitLab.

That split matters for anyone reading release notes or looking for a specific patch. The recent releases list for this repository is empty, so version history has to be followed on the GNOME infrastructure rather than here. The last push recorded for the mirror was on 2026-10-19.

For a project of this age and reach, that arrangement is not unusual, but it does change the workflow. If you plan to build from a released tarball, the archive URL is the place to start; if you plan to build from a git tree, the README makes clear you are working with Autotools sources that still need their configuration files generated.

Autotools, CMake and Meson all build the same C library

The README states that libxml2 can be built with GNU Autotools, CMake or meson, and each path has its own documented workflow. Autotools is aimed at POSIX systems like Linux, BSD and macOS, CMake is described as mainly for Windows, and Meson is presented as a third option with a separate options file.

The build requirements are modest by design: besides the build system tools, only a C compiler should be required. Two exceptions are named. Reconfiguring the Autotools build needs the pkg.m4 macro from pkg-config, and building the documentation needs Doxygen, xsltproc and the DocBook 4 XSLT stylesheets. Python bindings also require Doxygen, and they are off by default.

Platform support is stated as POSIX and Windows operating systems, with iconv treated as a hard requirement rather than an optional one.

Every --with- flag is a decision about what the library will parse

The Autotools option list is the clearest picture of what libxml2 can do, because each flag switches a code module and the symbols that go with it. The list spans Canonical XML 1.0, XML Catalogs, the HTML parser, XML Schemas 1.0, RELAX NG, DTD validation, XPath 1.0, XPointer, XInclude 1.0, the xmlPattern selection interface, the older SAX1 interface, the xmlReader and xmlWriter interfaces, push parser interfaces, serialization, regular expression support, multithreading and dynamic modules.

Several of those default to on. Others default to off and matter more than their one-line description suggests. ICU support is off, and the dependency section says using ICU is supported but discouraged. Schematron support is off. Documentation building is off. The --with-http flag does not restore HTTP support; it provides ABI compatibility for removed HTTP support, which tells you that the old HTTP client code is gone but its symbols remain visible to existing callers. --with-legacy and --with-minimum offer maximum ABI compatibility and a minimally sized library respectively.

A reviewer deciding on this library should treat that table as a checklist of attack surface and of installed size, not as a list of features to tick.

Building from a git tree on a POSIX system

The Autotools path is documented in enough detail to follow without guessing. From a git tree you need Autotools installed, and the first step generates the configuration files. From a source tarball you extract the archive and move into that directory. Either way, the sequence is configure, build, test, install.

    ./autogen.sh [configuration options]
    ./configure [configuration options]
    make
    make check
    make install

The `make check` step runs the test suite, and the README asks that test failures be reported to the bug tracker. After `make install` you may have to rerun ldconfig or a similar utility to update the list of installed shared libraries.

One detail deserves attention. The README notes that by default no optimization options are used, and that you have to enable them manually. The documented way to do that is to pass CFLAGS to configure, for example with CFLAGS='-O2 -fno-semantic-interposition' ./configure. Any build taken straight from the instructions will therefore be an unoptimized build, which matters when the library sits on a hot path.

CMake and Meson bring their own option vocabularies

The CMake flow is short and mostly for Windows: extract the tarball, configure into a build directory, build, run ctest against that build directory, then install. The CMake options mirror the Autotools switches under different names, including building static libraries, selecting a single-config or multi-config build type, setting the install prefix, and toggling iconv and zlib independently.

    cmake -E tar xf libxml2-xxx.tar.xz
    cmake -S libxml2-xxx -B builddir [options]
    cmake --build builddir
    ctest --test-dir builddir
    cmake --install builddir

The CMake path also opens in IDEs directly, since the source directory can be opened with its CMakeLists.txt in tools such as CLion, QtCreator or Visual Studio.

Meson follows the same shape with different verbs, and its options live in a separate meson_options.txt file, for example a prefix setting, enabling history, disabling schemas, and enabling zlib.

    meson setup [options] builddir
    ninja -C builddir
    meson test -C builddir
    ninja -C builddir install

Since iconv is required for conversion of character encodings and platforms without it need an external libiconv, the iconv switch is the option to check first on a new target.

The README tells you not to point it at untrusted XML

The security section of the README is unusually direct. The project describes itself as open-source software written by hobbyists and maintained by volunteers, and it states that it is NOT recommended to use the software to process untrusted data, because a maliciously crafted XML could exploit a hidden vulnerability. The software is provided as is, without warranty of any kind, express or implied.

For reporting, the project asks for a confidential issue with the security label, and says such reports are reviewed and worked on as a best effort. It then adds that if a security bug is critical for you, you are welcome to collaborate and provide a patch, because the project is a community one run by volunteers.

The social contract is stated just as plainly. The main rule is to be kind, and developers are asked not to be pressured into fixing a CVE or working on functionality you need, since that will not work. Security reporting therefore depends on the reporter being willing to contribute a fix. For an organisation that needs a predictable disclosure window, that is the part to weigh, and the README gives no support contract to point at.

C89 conformance, CI as the gate, and a ban on generated patches

The contributing section sets the technical bar: all code must conform to C89 and pass the GitLab CI tests, and regression tests are to be added if possible. The tree reflects that emphasis, with runsuite.c, runtest.c, runxmlconf.c and a result/ directory alongside the library sources, and a fuzz/ directory at the top level for fuzzing work.

The policy section is just as strict. It bans LLMs for issues, for patches and pull requests, and for comments on the bug tracker including translation. That is unusual for a project of this size and it applies to outside contributors as well as maintainers.

Licensing is described simply: the README states the code is released under the MIT License and points to the Copyright file, while the GitHub metadata for this mirror lists the licence as other, a classification GitHub cannot map automatically, with the LICENSE file as the reference. Contributors are asked to keep English usage encouraged in the tracker.

The last push was on 2026-10-19 and the repository is not archived, though this mirror publishes no GitHub releases, so release cadence has to be read from the GNOME download archive instead.

Editorial conclusion

libxml2 fits teams that already trust their XML inputs, ship GNOME-adjacent software in C, and want a single library covering SAX, DOM, XPath, RELAX NG, XInclude and serialization with configurable module flags. It does not fit services that accept XML from the network, and the README states that a crafted document could exploit a hidden vulnerability. Before adopting, decide which --with- flags you actually need, confirm your iconv situation because iconv is required for encoding conversion and ICU support is discouraged, and check whether your build runs with optimization enabled since the default is no optimization options at all.

Frequently asked questions

Official sources

1. GNOME/libxml2 on GitHub
2. Issues
3. Project website
4. README