fate of libxml2 in gcc

[Matthias Klose]

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 <jeffreyalaw@gmail.com> 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