I bring on the point James doesn't like to my suggestion, which is just
the effect that Jakub's suggestion has
* make it optionally in tree (like e.g. libisl is)
Users can download it (e.g. download_prerequisities does) and unpack
and then it is built in tree, or they don't and then it use system
libisl if it can find it (there are options to point it at a articular
library and its headers), or it is not found and not included.
* create an error /during XML PARSE / XML GENERATE from within libgcobol
if it isn't included - that would be a special XML-CODE (a register
for those two COBOL statements)
Reasoning:
* "easy to build"
* everything "external" -> the only maintenance is in the autotools part
* users can easily use the dependency script to download and then
statically sub-configure/make libxml2
* distros will use the system version if they can - which is no problem
Bad side (the understandable reason Jim dislikes that): a user may code
something that doesn't work - not sure if there are any GCC / glibc
parts which behave similar.
Simon
Am 16.01.2026 um 21:33 schrieb Jakub Jelinek:
On Fri, Jan 16, 2026 at 03:00:40PM -0500, James K. Lowden wrote:
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.
Note, while zlib is included in gcc tree, we have --with-system-zlib
option that users can use to use the system libz instead of the included
one.
And in tree vs. out of tree aren't the only options, there is also
the possibility to make it optionally in tree (like e.g. libisl is).
Users can download it (e.g. download_prerequisities does) and unpack
and then it is built in tree, or they don't and then it use system libisl
if it can find it (there are options to point it at a particular library and
its headers), or it is not found and not included.
I don't see why should libgcobol be a bootstrap library and how that would
help anything, that is for libraries which are needed during the bootstrap
(e.g. libiberty, libcpp, libstdc++ because gcc is now written mostly in C++,
libsanitizer libraries conditionally when doing the asan/ubsan checking
builds but normally not, etc.). The COBOL FE is not written in COBOL,
so I don't see why libgcobol should be a bootstrap library.
Jakub
