Bug 2340085

Created attachment 2068842 [details]
build.log

Created attachment 2068843 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Created attachment 2068844 [details]
state.log

*** Bug 2339707 has been marked as a duplicate of this bug. ***

Oh, this would be a tricky change. dnsmasq uses int iface_enumerate(int family, void *parm, int (*callback)()) function prototype to issue callbacks.

That has changed with recent compiler, it is considered int callback(void) now, instead of just unlisted parameters. Problem is, dnsmasq uses this function to call *different* set of parameters from different places, depending on whether handler function should process IPv4 or IPv6 addresses. It won't work to just add typedef of appropriate function, because there are conflicting possible definitions in the same function.

Example from network.c:

...
// Line 836
  ret = iface_enumerate(AF_INET6, &param, iface_allowed_v6);
  if (ret < 0)
    goto again;
  else if (ret)
    {
      ret = iface_enumerate(AF_INET, &param, iface_allowed_v4);
...

static int iface_allowed_v6(struct in6_addr *local,
                            int prefix, 
			    int scope,
                            int if_index,
                            int flags, 
			    int preferred,
                            int valid,
                            void *vparam);
static int iface_allowed_v4(struct in_addr local,
                            int if_index,
                            char *label,
			    struct in_addr netmask,
                            struct in_addr broadcast,
                            void *vparam);

These parameters are *very* different, creating common type does not seem to be simple. Perhaps explicit cast might solve it enough, hiding the problem more than solving it appropriately.

These callbacks do a bit different thing when called with different family to iface_enumerate. It implements common part at first, then changes behaviour to do different thing for AF_INET and AF_INET6, then quite different for AF_UNSPEC and also AF_LOCAL. Ideally these might be split to use static functions for common part, but otherwise have different iface_enumerate function with different callback function type. Because effectively they do significantly different tasks, which is not obvious on the first glance.

Anyway, this seems should be discussed on upstream list first.

There were already upstream report with this:
https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2024q4/017855.html

Gentoo bug: https://bugs.gentoo.org/945183

Which contains also working fix, although it is not very pretty.
It is applied at commit: https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=da2cc84854a01dd08a8bb4161428be20b83a5ec7

This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.

FEDORA-2025-7d03d3d62c (dnsmasq-2.90-6.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-7d03d3d62c