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.
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.
Matthias
