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. Richard. > Side note: > The way GnuCOBOL 2+3 does it is to "just link" libxml2 (our biggest, but > optional dependency) into the runtime "libcob". GnuCOBOL 4 - by default, > also possible to disable - has a shim library around it "libcob-xml" > which does the linking and is delay-loaded only upon use (allowing much > smaller distributions and dependencies as long as it isn't used at > runtime [or compile time, see above], while still having the full > feature-set with a single build [distros _could_ seperate libcob-xml out > of libcob]). > > Kind regards, > Simon
