Bug 2021814

It would be rebuilt with a rebase. I guess no separate rebuild would be needed.

Basic testing can be done when bind-devel is installed, before rebuild:
# rpm -q bind-libs --requires | grep json-c
libjson-c.so.4()(64bit)

# nm -D /usr/lib64/libisc.so | grep json_
                 U json_object_array_add
                 U json_object_new_array
                 U json_object_new_int
                 U json_object_new_int64
                 U json_object_new_object
                 U json_object_new_string
                 U json_object_object_add
                 U json_object_put

After rebuild with new json-c, json-c namespace should be added to symbols and to requires of new package:
# (checked on Fedora Rawhide, therefore soname bump is present)
# rpm -q bind-libs --requires | grep json-c
libjson-c.so.5()(64bit)
libjson-c.so.5(JSONC_0.14)(64bit)

Also symbols should include new namespace on undefined symbols, which should prevent collision in dynamic loader symbols.
nm -D /usr/lib64/libisc.so | grep json_
                 U json_object_array_add
                 U json_object_new_array
                 U json_object_new_int
                 U json_object_new_int64
                 U json_object_new_object
                 U json_object_new_string
                 U json_object_object_add
                 U json_object_put

I am not sure if this change is not breaking ABI for any binaries linked to previous version. New binary would not work without new json-c, which is okay. Old binary must work also with new json-c without recompilation, otherwise we may cause breaks to customer's own programs.

Forgot bind-libs-lite have to be tested in RHEL8, because it contains libisc.so and libdns.so, which references json-c functions.

Package dependencies to be checked:
# rpm -q bind-libs-lite --requires | grep json-c
libjson-c.so.4()(64bit)
libjson-c.so.4(JSONC_0.14)(64bit)

bind-libs dependency will stay without symbol and that is ok, because no code from those libraries uses json-c. RHEL9 have them merged together, but RHEL8 does not.

Maybe it is difference just inside nm utility. readelf can list also versioned symbols from json-c:

# readelf --dyn-syms /usr/lib64/libjson-c.so.* | grep @JSONC | tail
   177: 0000000000005170    70 FUNC    GLOBAL DEFAULT   13 json_object_object_get@@JSONC_0.14
   178: 0000000000003d70     9 FUNC    GLOBAL DEFAULT   13 array_list_length@@JSONC_0.14
   179: 0000000000005fe0    75 FUNC    GLOBAL DEFAULT   13 json_object_array_get_idx@@JSONC_0.14
   180: 0000000000005ef0    75 FUNC    GLOBAL DEFAULT   13 json_object_array_add@@JSONC_0.14
   181: 0000000000005c40    43 FUNC    GLOBAL DEFAULT   13 json_object_set_string@@JSONC_0.14
   182: 0000000000004ac0    19 FUNC    GLOBAL DEFAULT   13 json_object_get_userdata@@JSONC_0.14
   183: 0000000000005740    26 FUNC    GLOBAL DEFAULT   13 json_object_double_to_jso@@JSONC_0.14
   184: 0000000000004040   230 FUNC    GLOBAL DEFAULT   13 mc_info@@JSONC_0.14
   185: 0000000000003b90    27 FUNC    GLOBAL DEFAULT   13 array_list_get_idx@@JSONC_0.14
   186: 0000000000003e30    11 FUNC    GLOBAL DEFAULT   13 mc_get_debug@@JSONC_0.14

# LD_DEBUG=versions ldd /lib64/libisc.so.110? 2>&1 | grep -i json
     11931:	checking for version `JSONC_0.14' in file /lib64/libjson-c.so.4 [0] required by file /lib64/libisc.so.1107 [0]
     11931:	checking for version `GLIBC_2.3' in file /lib64/ld-linux-x86-64.so.2 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.8' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.14' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.3' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.4' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.2.5' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.3.4' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
	libjson-c.so.4 => /lib64/libjson-c.so.4 (0x00007f49b5d01000)

Some versioning information is present obviously. It would depend on how it is processed by dynamic loader. According to objdump it seems correct:
# objdump -T /lib64/libisc.so.110? | grep json_
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_object_add
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_new_int64
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_new_int
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_new_array
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_new_string
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_array_add
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_put
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_new_object

Where previous build has no namespace on those symbols:
# objdump -T /lib64/libisc.so.110? | grep json_
0000000000000000      DF *UND*	0000000000000000              json_object_new_string
0000000000000000      DF *UND*	0000000000000000              json_object_new_array
0000000000000000      DF *UND*	0000000000000000              json_object_put
0000000000000000      DF *UND*	0000000000000000              json_object_new_int64
0000000000000000      DF *UND*	0000000000000000              json_object_array_add
0000000000000000      DF *UND*	0000000000000000              json_object_new_object
0000000000000000      DF *UND*	0000000000000000              json_object_new_int
0000000000000000      DF *UND*	0000000000000000              json_object_object_add

so it seems okay. nm tool from binutils-2.30-110.el8.x86_64 does not just display what binutils-2.37-17.fc36.x86_64 can.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: bind security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:2092