On Fri, Jan 16, 2026 at 3:02 PM James K. Lowden <[email protected]> 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 > > > >
