fate of libxml2 in gcc

[David Edelsohn]

On Fri, Jan 16, 2026 at 3:02 PM James K. Lowden <jklowden@schemamania.org>
wrote:

> It is said of the Israeli knesset for every N people there are N + 2
> opinions.  Let us hope the GCC Steering Committee fares better with
> libxml2, because every choice has downsides.
>
> We are in need of a policy decision.  The question facing us is how
> best to integrate libxml2 into libgcobol.
>
> At present libgcobol requires the target to supply libxml2.  That
> complicates building cross compilers and mitigates against how
> distributions are normally built.  The remedy is to make libgcobol a
> bootstrap library, meaning AIUI that libraries it requires are built
> first, so that libgcobol can be built on a vanilla machine, from
> scratch, with the target providing nothing more than a C++ compiler.
>
> Issues:
>
> 1.  Bring libxml2 into the GCC repository, or not
> 2.  Link to libxml2 dynamically, or not
> 3.  Quality/stability of libxml2
> 4.  Maintenance burden in-tree versus build complexity ex-tree
> 5.  As of now libxml2 has no maintainer
>
> Thesis: Best is to build libxml2 out of tree and not install it, linking
> libxml2.a into libgcobol.
>
> The dilemma is whether or not to bring libxml2 into the gcc repository,
> as is done with zlib, or to support an out-of-tree build, meaning the
> user (who is building libgcobol) supplies libxml2 sources in a
> configurable location.
>
> If libxml2 becomes part of GCC, then yours truly bears the burden of
> dealing with CVE reports.  That is not a role I would accept with
> delight.  I have no particular expertise with the library; I'm just a
> user.  You also understand better than I the maintenance/support issues
> over the published lifetime of GCC releases.
>
> I think we're committed to static linking.  On the plus side, it limits
> problems introduced by libxml2 to those present specifically in the
> included version.  And, by linking statically, we guard against
> problems introduced by runtime dependency on a library that has
> historically not been very stable, and recently became officially
> unmaintained.  (Obligatory: https://xkcd.com/2347)  Obviously we lose
> the counter-benefit: the user cannot resolve problems associated with
> the statically linked libxml2 until an amended version of libgcobol is
> available.
>
> Doubtless there are other aspects I'm not aware of.
>
> It seems to me is the purpose of a healthy and open debate is to figure
> out the least bad option.  So I put it to you: to tree, or not to
> tree?  That is the question.


I assume that the suggestion of requiring libxml2 only would apply when
building libgcobol.

Another issue is that the maintenance of libxml2 seems precarious.

I will raise the issue with the GCC Steering Committee.

Thanks, David


>
>
> --jkl
>
>
>
>