Horton

Thread

Commits

  1. xml2: Replace deprecated routines with recommended ones

  1. Time to back-patch libxml deprecation fixes?

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-04-15T23:14:22Z

    I just noticed that my animal indri has been failing in the
back branches since I updated its MacPorts packages a few
days ago:

ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Werror=unguarded-availability-new -Wendif-labels -Wmissing-format-attribute -Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -g -O2 -fno-common -Werror  -fvisibility=hidden -I. -I. -I../../src/include -I/opt/local/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk  -I/opt/local/include/libxml2 -I/opt/local/include -I/opt/local/include -I/opt/local/include  -I/opt/local/include  -c -o mbuf.o mbuf.c
xpath.c:77:2: error: 'xmlSubstituteEntitiesDefault' is deprecated [-Werror,-Wdeprecated-declarations]
        xmlSubstituteEntitiesDefault(1);
        ^
/opt/local/include/libxml2/libxml/parser.h:952:1: note: 'xmlSubstituteEntitiesDefault' has been explicitly marked deprecated here
XML_DEPRECATED XMLPUBFUN int
^
/opt/local/include/libxml2/libxml/xmlversion.h:447:43: note: expanded from macro 'XML_DEPRECATED'
#    define XML_DEPRECATED __attribute__((deprecated))
                                          ^
1 error generated.
make[1]: *** [xpath.o] Error 1

I could switch the animal to use -Wno-deprecated-declarations in the
back branches, but I'd rather not.  I think the right answer is to
back-patch Michael's 65c5864d7 (xml2: Replace deprecated routines with
recommended ones).  We speculated about that at the time (see e.g.,
400928b83) but didn't pull the trigger.  I think 65c5864d7 has now
baked long enough that it'd be safe to back-patch.

			regards, tom lane

  2. Re: Time to back-patch libxml deprecation fixes?

    Andres Freund <andres@anarazel.de> — 2024-04-15T23:20:43Z

    Hi,

On 2024-04-15 19:14:22 -0400, Tom Lane wrote:
> I think the right answer is to
> back-patch Michael's 65c5864d7 (xml2: Replace deprecated routines with
> recommended ones).  We speculated about that at the time (see e.g.,
> 400928b83) but didn't pull the trigger.  I think 65c5864d7 has now
> baked long enough that it'd be safe to back-patch.

Looks like a reasonable plan to me.

Greetings,

Andres Freund

  3. Re: Time to back-patch libxml deprecation fixes?

    Michael Paquier <michael@paquier.xyz> — 2024-04-15T23:30:46Z

    On Mon, Apr 15, 2024 at 07:14:22PM -0400, Tom Lane wrote:
> I could switch the animal to use -Wno-deprecated-declarations in the
> back branches, but I'd rather not.  I think the right answer is to
> back-patch Michael's 65c5864d7 (xml2: Replace deprecated routines with
> recommended ones).  We speculated about that at the time (see e.g.,
> 400928b83) but didn't pull the trigger.  I think 65c5864d7 has now
> baked long enough that it'd be safe to back-patch.

Yeah, I saw the failure with indri this morning while screening the
buildfarm, and was going to send a message about that.  Backpatching
65c5864d7 would be the right answer to that, agreed, and that should
be rather straight-forward.

Note however the presence of xml_is_well_formed in the back-branches,
where there is an extra xmlParseMemory that needs to be switched to
xmlReadMemory but that's a simple switch.

Would you prefer if I do it?
--
Michael

  4. Re: Time to back-patch libxml deprecation fixes?

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-04-15T23:42:38Z

    Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Apr 15, 2024 at 07:14:22PM -0400, Tom Lane wrote:
>> I could switch the animal to use -Wno-deprecated-declarations in the
>> back branches, but I'd rather not.  I think the right answer is to
>> back-patch Michael's 65c5864d7 (xml2: Replace deprecated routines with
>> recommended ones).  We speculated about that at the time (see e.g.,
>> 400928b83) but didn't pull the trigger.  I think 65c5864d7 has now
>> baked long enough that it'd be safe to back-patch.

> Would you prefer if I do it?

Please, if you have the time.

			regards, tom lane

  5. Re: Time to back-patch libxml deprecation fixes?

    Michael Paquier <michael@paquier.xyz> — 2024-04-16T03:34:45Z

    On Mon, Apr 15, 2024 at 07:42:38PM -0400, Tom Lane wrote:
> Please, if you have the time.

Okay, done that in the 12~16 range then, removing all traces of
xmlParseMemory() including for xml_is_well_formed() in 12~14.  That
should calm down indri.
--
Michael

  6. Re: Time to back-patch libxml deprecation fixes?

    Tom Lane <tgl@sss.pgh.pa.us> — 2024-04-16T03:56:40Z

    Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Apr 15, 2024 at 07:42:38PM -0400, Tom Lane wrote:
>> Please, if you have the time.

> Okay, done that in the 12~16 range then, removing all traces of
> xmlParseMemory() including for xml_is_well_formed() in 12~14.  That
> should calm down indri.

Thanks!

			regards, tom lane

  7. Re: Time to back-patch libxml deprecation fixes?

    Michael Paquier <michael@paquier.xyz> — 2024-04-16T04:44:23Z

    On Mon, Apr 15, 2024 at 11:56:40PM -0400, Tom Lane wrote:
> Thanks!

indri has reported on some branches, and is now green for
REL_12_STABLE and REL_13_STABLE.  The rest should be OK.
--
Michael