❮

Time to back-patch libxml deprecation fixes?

  • Jump to comment-1
    tgl@sss.pgh.pa.us2024-04-15T23:14:32+00:00
    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
    • Jump to comment-1
      andres@anarazel.de2024-04-15T23:20:53+00:00
      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
    • Jump to comment-1
      michael@paquier.xyz2024-04-15T23:31:12+00:00
      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
      • Jump to comment-1
        tgl@sss.pgh.pa.us2024-04-15T23:42:44+00:00
        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
        • Jump to comment-1
          michael@paquier.xyz2024-04-16T03:35:06+00:00
          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
          • Jump to comment-1
            tgl@sss.pgh.pa.us2024-04-16T03:56:47+00:00
            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
            • Jump to comment-1
              michael@paquier.xyz2024-04-16T04:44:52+00:00
              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