Time to back-patch libxml deprecation fixes?

Started by Tom Laneover 1 year ago7 messages
#1Tom Lane
tgl@sss.pgh.pa.us

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

#2Andres Freund
andres@anarazel.de
In reply to: Tom Lane (#1)
Re: Time to back-patch libxml deprecation fixes?

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

#3Michael Paquier
michael@paquier.xyz
In reply to: Tom Lane (#1)
Re: Time to back-patch libxml deprecation fixes?

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

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Paquier (#3)
Re: Time to back-patch libxml deprecation fixes?

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

#5Michael Paquier
michael@paquier.xyz
In reply to: Tom Lane (#4)
Re: Time to back-patch libxml deprecation fixes?

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

#6Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Paquier (#5)
Re: Time to back-patch libxml deprecation fixes?

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

#7Michael Paquier
michael@paquier.xyz
In reply to: Tom Lane (#6)
Re: Time to back-patch libxml deprecation fixes?

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