On Mon, Jan 19, 2026 at 5:48 AM Matthias Klose <[email protected]> wrote: > > On 1/18/26 21:15, Jeffrey Law wrote: > > > > > > On 1/18/2026 1:00 PM, James K. Lowden wrote: > >> On Fri, 16 Jan 2026 16:44:37 -0700 > >> Jeffrey Law <[email protected]> wrote: > >> > >>> 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, > >>> So does libxml2 get linked into target code? Or libxml2 needed to > >>> build the compiler itself? > >> The gcobol compiler does not use libxml2. libgcobol mediates between > >> libxml2 and the compiled COBOL program. By that means, libxml2 is > >> linked into the target code. > >> > >> When libgcobol is built, it is linked to libxml2 because libgcobol > >> provides support for the XML PARSE statement in COBOL. The > >> compiled COBOL program is linked to libgcobol, which is linked to > >> libxml2, which is -- somehow -- provided by the target environment. > >> > >> As of now, libgcobol/configure.ac confirms that libxml2 is installed. > >> The build relies on the host to supply the header files and library. > > But is libgcobol target or not? Based on the above it sounds like it's > > target side. > > unlike mpfr, gmp, isl, which are only needed for the host, libxml2 is > needed for the target. libgcobol is not needed for a bootstrap. We > have a similar relationship for libgo/libffi, libphobos and zlib (where > the latter is built in-tree for the target), or with libobjc, configured > for boehm-gc and bdw-gc which needs to be provided for the target. > > > Ultimately the question that I'm looking to get answered is where does > > the libxml2 code run? Is it for the host, build or target machine? > > > > We don't include the C library with GCC, but we do include the C++ > > runtime library with GCC. The decisions here aren't necessarily that > > clear cut. > > problems are usually seen when building for multilib targets, and cross > compilers. > > - for multilib builds, you need to provide the target lib for > each multilib build. libobjc has options --with-target-bdw-gc, > --with-target-bdw-gc-include and --with-target-bdw-gc-lib. > You may argue that multilibs aren't needed for libgcobol, because > it only targets 64bit. And I haven't tried building a 64bit libgcobol > for a ix86 host yet. > > - for cross compilers, you need either build the target libxml2 > before you start building the cross compiler, or you need to build > it in-tree during the build. For packaging a cross compilers, > that makes the cross build a two-stage step, first building a C/C++ > cross compiler, then building libxml2, then rebuilding the > cross compiler including the cobol front-end. > > Unless the objc frontend, where the bdw-gc is an optional thing, > libxml2 is required by libgcobol.
IMO the current setup is perfectly adequate. Yes, you need to provide target libxml libraries for all multilibs at GCC cross build time which might be inconvenient but it's just that. In theory we could -Wl,--allow-undefs on libgcobol and either just at a DT_NEEDED to libxml2 (is that possible?) or arrange for the gcobol driver to -lxml2 when building cobol applications. > So what is needed, are configure options like the ones for bdw-gc to > point to a pre-built libxml2. It might not be necessary to provide these > suited for a multilib target. > > It's optional to have a libgcobol.so dependency on libxml2, or to > include the PIC compiled objects explicitly, like libgo is including the > libffi object files as a convenience library. But for the latter, there > is no direct configury available like there is for the in-tree libffi. > > Having libxml2 in-tree eases the build of the cross compilers and > probably eases the build of multilib builds. Having it provided > externally, complicates the cross build, including to get it built as a > convenience library. In any case, we need some configuration options > added to find it, and the requirements for a libxml2 build documented. And this IMO is a nice-to-have thing, and it's best provided by people who actually will use it (and thus will test it!). It should not be a requirement put on the COBOL maintainers. Richard. > Matthias >
