On 2025-10-21 18:18, James K. Lowden wrote:
On Tue, 21 Oct 2025 17:41:51 -0400
David Malcolm <[email protected]> wrote:
Ideally libgcobol would be dynamically linked against a "system copy"
of libxml2, at which point the mitigation story for the user becomes:
update the system copy of libxml2
That is the plan, yes, to the extent we control it. When building
libgcobol, the command line includes "-lxml2". How the linker finds
it, and whether or not it's the "system copy" is above my pay
grade. ;-)
The standard way to deal with this is to add it to a configure check and
then let the user deal with it the way they want to, i.e. install a
system library or install the library in a bespoke location and point
the gcc build system to it using environment variables or configure flags.
Sorry if it seems either like (a) I'm picking on you
Not at all.
hesitate to accept libxml2 as a mandatory dependency for all of
gcc
I would, too. It's a mandatory component of the runtime library of an
optional language, which technically makes it the lesser weevil.
Of course it could be made optional. But the that doesn't make the
user's life better. If libxml2 is excluded at install time -- perhaps
by the packager -- then the user goes along merrily until he tries to
use the syntax. It's a lousy experience.
To me, it's safe to assume that corporate security policy deals with
this stuff all the time. Right now, we have users who *want* this
feature. If in the future we have users who specifically want to ban
it, well, not for nothing it's called free software.
IMO the best way forward here would be adding a configure check for
libxml2 specifically for libgcobol (and maybe gcc/cobol if the frontend
needs it too). If the configure check fails, it's your choice to decide
whether the build fails altogether (e.g. by failing the configure step
at which point the user may either decide to install the libxml2 dev
package to get the libraries to link against, or disable the cobol
frontend) or it disables only parts of the language implementation that
need libxml2 with the "sorry" diagnostic David mentioned. If it's
strictly a runtime feature, then the change would likely also end up
having a runtime program termination component to it.
I'm partial to the second approach (i.e. conditional enablement of the
feature subset) since that continues to support users that don't need
the feature that depends on XML parsing, but I have no idea what the
user base wants here :)
Thanks,
Sid
