FTBFS with glibc 2.34

[sergiodj]

Hi,

dnsdbq FTBFS when compiled against glibc 2.34:

asinfo.c: In function ‘asinfo_from_dns’:
asinfo.c:194:17: error: ‘__p_rcode’ is deprecated [-Werror=deprecated-declarations]
  194 |                 return p_rcode(rcode);
      |                 ^~~~~~
In file included from asinfo.c:33:
/usr/include/resolv.h:259:17: note: declared here
  259 | const char *    p_rcode (int) __THROW __RESOLV_DEPRECATED;
      |                 ^~~~~~~
cc1: all warnings being treated as errors

This is happening because glibc 2.34 deprecated quite a few functions from resolv.h (libresolv), according to their announcement at https://lists.gnu.org/archive/html/info-gnu/2021-08/msg00001.html:

* Various rarely-used functions declared in <resolv.h> and
  <arpa/nameser.h> have been deprecated.  Applications are encouraged to
  use dedicated DNS processing libraries if applicable.  For <resolv.h>,
  this affects the functions dn_count_labels, fp_nquery, fp_query,
  fp_resstat, hostalias, loc_aton, loc_ntoa, p_cdname, p_cdnname,
  p_class, p_fqname, p_fqnname, p_option, p_query, p_rcode, p_time,
  p_type, putlong, putshort, res_hostalias, res_isourserver,
  res_nameinquery, res_queriesmatch, res_randomid, sym_ntop, sym_ntos,
  sym_ston.  For <arpa/nameser.h>, the functions ns_datetosecs,
  ns_format_ttl, ns_makecanon, ns_parse_ttl, ns_samedomain, ns_samename,
  ns_sprintrr, ns_sprintrrf, ns_subdomain have been deprecated.

FWIW, this was detected when building the dnsdbq package in Ubuntu Jammy (development version):

https://launchpadlibrarian.net/578748547/buildlog_ubuntu-jammy-amd64.dnsdbq_2.6.0-2_BUILDING.txt.gz

[vixie]

since i wrote that part of libresolv, and i have always used it, i consider ubuntu's treatment to be bizarre. #wontfix.

[sergiodj]

Sorry, I don't understand your reply.

This bug is absolutely not Ubuntu-specific. It is happening because of an upstream change that glibc implemented on version 2.34, and which impacts dnsdbq regardless of the distribution it is being built on. The exact same problem can be easily reproduced if you try to compile dnsdbq on Fedora 35 (which ships glibc 2.34), for example.

[vixie]

i guess with their audience size they can afford to piss people off. what's your recommendation? just copy p_rcode into dnsdbq? or add a dependency on the real libresolv and make everybody download that before building this?

[sergiodj]

I think the first option would be more suitable, at least in the short term.

glibc's intention is to eventually move libresolv inside it (glibc) entirely, so that it won't be necessary to provide -lresolv in order to link against libresolv. They already did this for libpthread (see https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread).

The downside is that dnsdbq's copy of p_rcode can become out-of-sync with glibc's, but as I said, I see this more as a short term solution anyway.

Thanks.

[vixie]

they should adopt all of the library they wish to include in glibc. or they should publish a replacement library containing the symbols they do not wish to import. what they are doing is insulting and destructive and arrogant, and it's breaking working code and forcing other people to adapt to their values and their mission. this is "evil" by the dictionary definition.

please submit a pull request that demotes p_rcode() from libresolv to a dnsdbq symbol. but seriously, fsck those guys.

[djw1149]

It's a non-BSD thing having the resolver functions in a separate libresolv. Our Makefile describes removing -lresolv if building on FreeBSD. Linux is moving towards how BSD did it.
Vixie, please note the author of the above Redhat.com article: Florian Weimer. Maybe he would be sympathetic to adding back some of the removed functions, as a passive DNS architect?

[vixie]

fix was merged.