net-snmp @5.8: error: implicit declaration of function 'get_in_address' is invalid in C99

[Prolixium]

From what I can tell on a fresh install of macOS Big Sur (11.0.1) and Xcode 12.2 w/MacPorts 2.6.4, net-snmp 5.8 fails to compile:

/bin/sh ../../libtool  --mode=compile /usr/bin/clang -I../../include -I. -I../../agent -I../../agent/mibgroup  -I../../snmplib -I/opt/local/include -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk  -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk -arch x86_64 -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -DNETSNMP_REMOVE_U64 -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk -arch x86_64 -Udarwin20 -Ddarwin20=darwin20  -c -o mibII/ipAddr.lo mibII/ipAddr.c
mibgroup/mibII/ipAddr.c:200:29: error: variable has incomplete type 'struct in_ifaddr'
    static struct in_ifaddr in_ifaddr, lowin_ifaddr;
                            ^
mibgroup/mibII/ipAddr.c:200:19: note: forward declaration of 'struct in_ifaddr'
    static struct in_ifaddr in_ifaddr, lowin_ifaddr;
                  ^
mibgroup/mibII/ipAddr.c:200:40: error: variable has incomplete type 'struct in_ifaddr'
    static struct in_ifaddr in_ifaddr, lowin_ifaddr;
                                       ^
mibgroup/mibII/ipAddr.c:200:19: note: forward declaration of 'struct in_ifaddr'
    static struct in_ifaddr in_ifaddr, lowin_ifaddr;
                  ^
mibgroup/mibII/ipAddr.c:204:25: error: variable has incomplete type 'struct ifnet'
    static struct ifnet ifnet;
                        ^
mibgroup/mibII/ipAddr.c:204:19: note: forward declaration of 'struct ifnet'
    static struct ifnet ifnet;
                  ^
mibgroup/mibII/var_route.c:195:29: error: implicit declaration of function 'get_in_address' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
            cp = (u_char *) get_in_address((struct sockaddr *) (rtp + 1),
                            ^
3 errors generated.
mibgroup/mibII/var_route.c:195:18: warning: cast to 'u_char *' (aka 'unsigned char *') from smaller integer type 'int' [-Wint-to-pointer-cast]
            cp = (u_char *) get_in_address((struct sockaddr *) (rtp + 1),
                 ^
mibgroup/mibII/var_route.c:235:27: error: implicit declaration of function 'get_in_address' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        return (u_char *) get_in_address((struct sockaddr *) (rtp + 1),
                          ^
mibgroup/mibII/var_route.c:235:16: warning: cast to 'u_char *' (aka 'unsigned char *') from smaller integer type 'int' [-Wint-to-pointer-cast]
        return (u_char *) get_in_address((struct sockaddr *) (rtp + 1),
               ^
mibgroup/mibII/var_route.c:269:13: warning: cast to 'u_char *' (aka 'unsigned char *') from smaller integer type 'int' [-Wint-to-pointer-cast]
        return (u_char *) get_in_address((struct sockaddr *) (rtp + 1),
               ^
mibgroup/mibII/var_route.c:299:20: warning: cast to 'u_char *' (aka 'unsigned char *') from smaller integer type 'int' [-Wint-to-pointer-cast]
            return (u_char *) get_in_address((struct sockaddr *) (rtp + 1),
                   ^
mibgroup/mibII/var_route.c:2110:1: error: conflicting types for 'get_in_address'
get_in_address(const void *ap, int addresses, int wanted)
^
mibgroup/mibII/var_route.c:195:29: note: previous implicit declaration is here
            cp = (u_char *) get_in_address((struct sockaddr *) (rtp + 1),
                            ^
4 warnings and 3 errors generated.

If I'm reading the port summary page correctly, there might not be a working build for Catalina either, and Mojave was the last OS where the port built successfully.

I'm attaching net-snmp-build.txt that shows all the messages from the failed build.

Please let me know if there's anything I should try or anything additional I can include in this ticket. Thanks!

[Prolixium]

build text

[ryandesign (Ryan Carsten Schmidt)]

The port summary page is not the final word on whether a port built or not. We do have net-snmp packages available for all OS versions up to and including Catalina; see ​https://packages.macports.org/net-snmp/

This is the well-known Xcode 12 implicit function declaration issue.

[kencu (Ken)]

FYI even when I disabled the implicit function issue, it would not build due to this:

error: variable has incomplete type 'struct in_ifaddr'

[ryandesign (Ryan Carsten Schmidt)]

As far as I recall, that error message is also indicative of forgetting to include the right header.

[kencu (Ken)]

oh, that would be great then.

[miken32 (Michael Newton)]

Is there anything we can do to help resolve this issue? Any patches to test, or upstream bugs to file? I'm not a C programmer, but my understanding is this function just needs to be pre-declared either at the top of the file or in a header file. Since it violates current C standards, it seems like it's a no-brainer to just add it to the header but I assume there's some drawback?

[amake (Aaron Madlon-Kay)]

I have an incomplete PR up to bump the version and fix the build, but the last mile is unfortunately beyond my current abilities: ​https://github.com/macports/macports-ports/pull/9506

If someone could help out that would be great.

[Aaron Madlon-Kay <amake@…>]

In 4c628cac76d0e5ee79c3bbe8c6679ca7f627b064/macports-ports (master):

net-snmp: update to 5.9 (​https://github.com/macports/macports-ports/pull/9506)

Fixes #61624

[ryandesign (Ryan Carsten Schmidt)]

Aaron, this update changed the library's major version (libnetsnmp.35.dylib became libnetsnmp.40.dylib) so everything that was linked to the old library is now broken, e.g.:

$ php70 -v
PHP Warning:  PHP Startup: Unable to load dynamic library '/opt/local/lib/php70/extensions/no-debug-non-zts-20151012/snmp.so' - dlopen(/opt/local/lib/php70/extensions/no-debug-non-zts-20151012/snmp.so, 9): Library not loaded: /opt/local/lib/libnetsnmp.35.dylib
  Referenced from: /opt/local/lib/php70/extensions/no-debug-non-zts-20151012/snmp.so
  Reason: image not found in Unknown on line 0

You must revbump everything that links with the library (that has not already been revbumped or otherwise updated since then). Determining whether this is necessary, and doing it, are part of your responsibility when you update a port that provides a library.