Richard Biener <[email protected]> writes: > On Sat, Jan 17, 2026 at 12:46 PM Simon Sobisch via Gcc <[email protected]> > wrote: >> >> >> Am 17.01.2026 um 00:44 schrieb Jeffrey Law: >> > >> > On 1/16/2026 1:00 PM, James K. Lowden wrote: >> >> >> >> 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. >> > Let's get some clarity on this paragraph. You say "requires the target >> > to supply libxml2". I could read that a couple different ways and the >> > differences are likely meaningful. >> > >> > So does libxml2 get linked into target code? Or libxml2 needed to build >> > the compiler itself? >> > >> > In the former case, we'd likely need a copy in the tree managed like we >> > do with other target libraries. If it's the later, then we have a lot >> > more flexibility. >> > >> > Jeff >> >> Only in the compiler itself - libgcobol wraps all calls and therefore it >> is only needed "there". Also it won't use every part of libxml2 >> (obviously) so part of its CVEs in the last years won't "apply" if >> static linking woulds be done (and the unused symbols be optimized out). > > I think one important part is to make the use of libxml from libgcobol an > implementation detail and not part of its ABI which means making sure > to not export any libxml symbols from libgcobol. With my GCC distributors > hat on I'd prefer dynamic linking of libxml to libgcobol rather than having > to track libxml CVEs similar as to how I'm using --with-system-zlib. > > As to in-tree building, when somebody wants this he can propose a patch > to add support. > >> Background: >> It is needed to implement two COBOL statements handling XML generation >> from pre-defined data in pre-defined structure (easy) and parsing >> "anything in stream mode / chunks" - which "surprisingly" matches the >> ABI of libxml2. >> I'd expect the compiler gcobol to also use it for pre-validation of >> encodings and other parts if those are coded as literals in COBOL. > > I wonder if going the libgfortran/libquadmath way would be another possibility > to avoid having all COBOL programs depend on libxml? That is, link > libxml2 to the program (as-needed) and have the frontend generate calls > into libxml2 rather than dispatching through libgcobol.
I rather like this option, and to me, it is the only viable option other than having it in-tree: libxml2's ABI has over the last few years proven very unstable, with features being deprecated & removed either w/ no SONAME bump, or a delayed one. It's the opposite of zlib wrt stability. Imposing a rebuild of GCC for users or manually updating a copy of (distro bundled) libxml2 in our GCC package (as I understand I think at least RHEL et al are doing for isl?) are both undesirable. > Richard sam
signature.asc
Description: PGP signature
