git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’

git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’

[Jeffrey Walton]

Hi Everyone,

I'm building the 2.25 release tarball on Solaris 11.3 i86pc. I'm
catching an error:

$ gmake
    CC fuzz-commit-graph.o
In file included from commit-graph.h:4:0,
                 from fuzz-commit-graph.c:1:
git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’
 const char *inet_ntop(int af, const void *src, char *dst, size_t size);
             ^
In file included from git-compat-util.h:226:0,
                 from commit-graph.h:4,
                 from fuzz-commit-graph.c:1:
/usr/include/arpa/inet.h:43:20: note: previous declaration of
‘inet_ntop’ was here
 extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,
                    ^
gmake: *** [fuzz-commit-graph.o] Error 1

And:

$ cat -n /usr/include/arpa/inet.h
...
    41  #if !defined(_XPG4_2) || defined(_XPG6) || defined(__EXTENSIONS__)
    42  extern int inet_pton(int, const char *_RESTRICT_KYWD, void
*_RESTRICT_KYWD);
    43  extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,
    44                          char *_RESTRICT_KYWD, socklen_t);
    45  #endif /* !defined(_XPG4_2) || defined(_XPG6) ||
defined(__EXTENSIONS__) */

Jeff

Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’

[Jeffrey Walton]

On Sat, Feb 1, 2020 at 6:39 AM Jeffrey Walton <noloader@gmail.com> wrote:
>
> I'm building the 2.25 release tarball on Solaris 11.3 i86pc. I'm
> catching an error:
>
> $ gmake
>     CC fuzz-commit-graph.o
> In file included from commit-graph.h:4:0,
>                  from fuzz-commit-graph.c:1:
> git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’
>  const char *inet_ntop(int af, const void *src, char *dst, size_t size);
>              ^
> In file included from git-compat-util.h:226:0,
>                  from commit-graph.h:4,
>                  from fuzz-commit-graph.c:1:
> /usr/include/arpa/inet.h:43:20: note: previous declaration of
> ‘inet_ntop’ was here
>  extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,
>                     ^
> gmake: *** [fuzz-commit-graph.o] Error 1
>
> And:
>
> $ cat -n /usr/include/arpa/inet.h
> ...
>     41  #if !defined(_XPG4_2) || defined(_XPG6) || defined(__EXTENSIONS__)
>     42  extern int inet_pton(int, const char *_RESTRICT_KYWD, void
> *_RESTRICT_KYWD);
>     43  extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,
>     44                          char *_RESTRICT_KYWD, socklen_t);
>     45  #endif /* !defined(_XPG4_2) || defined(_XPG6) ||
> defined(__EXTENSIONS__) */

According to Sun's man pages:

inet(3SOCKET)              Sockets Library Functions             inet(3SOCKET)

NAME
       inet,  inet6, inet_ntop, inet_pton, inet_aton, inet_addr, inet_network,
       inet_makeaddr, inet_lnaof, inet_netof,  inet_ntoa  -  Internet  address
       manipulation

SYNOPSIS
       cc [ flag... ] file... -lsocket  -lnsl  [ library... ]
       #include <sys/socket.h>
       #include <netinet/in.h>
       #include <arpa/inet.h>

Maybe the include should be <arpa/inet.h> on Sun systems?

I was able to hack around it with the following after configure:

    # Solaris 11.3 work-around. The OS has inet_ntop and inet_pton
    for file in $(find "$PWD" -name 'Makefile')
    do
        sed '/ifdef NO_INET_NTOP/,+3 d' "$file" > "$file.fixed"
        mv "$file.fixed" "$file"
        sed '/ifdef NO_INET_PTON/,+3 d' "$file" > "$file.fixed"
        mv "$file.fixed" "$file"
    done

Jeff

Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’

[Jeffrey Walton]

On Sat, Feb 1, 2020 at 7:12 AM Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Sat, Feb 1, 2020 at 6:39 AM Jeffrey Walton <noloader@gmail.com> wrote:
> >
> > I'm building the 2.25 release tarball on Solaris 11.3 i86pc. I'm
> > catching an error:
> >
> > $ gmake
> >     CC fuzz-commit-graph.o
> > In file included from commit-graph.h:4:0,
> >                  from fuzz-commit-graph.c:1:
> > git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’
> >  const char *inet_ntop(int af, const void *src, char *dst, size_t size);
> >              ^
> > In file included from git-compat-util.h:226:0,
> >                  from commit-graph.h:4,
> >                  from fuzz-commit-graph.c:1:
> > /usr/include/arpa/inet.h:43:20: note: previous declaration of
> > ‘inet_ntop’ was here
> >  extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,
> >                     ^
> > gmake: *** [fuzz-commit-graph.o] Error 1
> >
> > And:
> >
> > $ cat -n /usr/include/arpa/inet.h
> > ...
> >     41  #if !defined(_XPG4_2) || defined(_XPG6) || defined(__EXTENSIONS__)
> >     42  extern int inet_pton(int, const char *_RESTRICT_KYWD, void
> > *_RESTRICT_KYWD);
> >     43  extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,
> >     44                          char *_RESTRICT_KYWD, socklen_t);
> >     45  #endif /* !defined(_XPG4_2) || defined(_XPG6) ||
> > defined(__EXTENSIONS__) */
>
> According to Sun's man pages:
>
> inet(3SOCKET)              Sockets Library Functions             inet(3SOCKET)
>
> NAME
>        inet,  inet6, inet_ntop, inet_pton, inet_aton, inet_addr, inet_network,
>        inet_makeaddr, inet_lnaof, inet_netof,  inet_ntoa  -  Internet  address
>        manipulation
>
> SYNOPSIS
>        cc [ flag... ] file... -lsocket  -lnsl  [ library... ]
>        #include <sys/socket.h>
>        #include <netinet/in.h>
>        #include <arpa/inet.h>
>
> Maybe the include should be <arpa/inet.h> on Sun systems?

This may be part of the issue, too.

    checking for socket in -lc... no
    checking for inet_ntop... no
    checking for inet_ntop in -lresolv... no
    checking for inet_pton... no
    checking for inet_pton in -lresolv... no

-lsocket  -lnsl should probably be tested.

Jeff

Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’

[Jeff King]

On Sat, Feb 01, 2020 at 07:12:21AM -0500, Jeffrey Walton wrote:

> Maybe the include should be <arpa/inet.h> on Sun systems?

It is included already. I think the real problem is that we are
declaring our own replacement inet_ntop(), which then conflicts with the
system one.

> I was able to hack around it with the following after configure:
> 
>     # Solaris 11.3 work-around. The OS has inet_ntop and inet_pton
>     for file in $(find "$PWD" -name 'Makefile')
>     do
>         sed '/ifdef NO_INET_NTOP/,+3 d' "$file" > "$file.fixed"
>         mv "$file.fixed" "$file"
>         sed '/ifdef NO_INET_PTON/,+3 d' "$file" > "$file.fixed"
>         mv "$file.fixed" "$file"
>     done

As you found there's a knob for this already. Building with:

  make NO_INET_NTOP= NO_INET_PTON=

to clear those flags would probably work (as would putting those
variables in your config.mak file).

But having those variables unset is already the default. The root of the
problem is likely that the autoconf test seems to get the wrong result
on Solaris (another workaround would be to remove them from
config.mak.autogen, but that will get obliterated next time you run
./configure).

The real fix would be teaching configure.ac to check for the correct
libraries (it looks like it has a -lsocket test already; I'm not sure if
that isn't being used in the test-compile for inet_ntop(), or if we need
to also be adding libraries like -lnsl).

I suspect that running autoconf with CFLAGS='-lsocket -lnsl' in the
environment might also make the problem go away, but it's been a long
enough time since I touched anything related to autoconf that I'm not
sure.

This also seems eerily familiar:

  https://lore.kernel.org/git/CAH8yC8kOj5a5PN4V7mj7xZPoNDr-MH-CkirxRKyfx1-qAvfpqQ@mail.gmail.com/

:) I second Junio's notion there that you may be better off skipping
./configure entirely.

-Peff

Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’

[Jeffrey Walton]

On Mon, Feb 3, 2020 at 3:54 AM Jeff King <peff@peff.net> wrote:
>
> On Sat, Feb 01, 2020 at 07:12:21AM -0500, Jeffrey Walton wrote:
>
> > Maybe the include should be <arpa/inet.h> on Sun systems?
> ...
> This also seems eerily familiar:
>
>   https://lore.kernel.org/git/CAH8yC8kOj5a5PN4V7mj7xZPoNDr-MH-CkirxRKyfx1-qAvfpqQ@mail.gmail.com/
>
> :) I second Junio's notion there that you may be better off skipping
> ./configure entirely.Thanks Jeff.

I run 'make configure' and configure because that's what the INSTALL
tells me to do.

Forgive my ignorance... If I don't run configure, then how do I
configure things?

Jeff

Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’

[Jeff King]

On Mon, Feb 03, 2020 at 03:59:19AM -0500, Jeffrey Walton wrote:

> > :) I second Junio's notion there that you may be better off skipping
> > ./configure entirely.Thanks Jeff.
> 
> I run 'make configure' and configure because that's what the INSTALL
> tells me to do.
> 
> Forgive my ignorance... If I don't run configure, then how do I
> configure things?

Above the "Alternatively you can use autoconf..." in INSTALL, there is:

  The beginning of the Makefile documents many variables that affect the
  way git is built.  You can override them either from the command line,
  or in a config.mak file.

You often don't need to set most of those flags, because
config.mak.uname picks some defaults based on the platform we find via
"uname".

So I'd first just try "make" without any config. If that doesn't work
out of the box, a patch to update config.mak.uname would be welcome.

If "./configure && make" also doesn't work, certainly patches are
welcome there, too. The reason I say you may be better off skipping it
is that historically it seems to not be kept as up-to-date. Usually it
would not make things _worse_ to run it, but in this inet_ntop case, I
think it does.

-Peff

Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’

[Jeffrey Walton]

...
> But having those variables unset is already the default. The root of the
> problem is likely that the autoconf test seems to get the wrong result
> on Solaris (another workaround would be to remove them from
> config.mak.autogen, but that will get obliterated next time you run
> ./configure).

Thanks Jeff.

Below is from configure.ac around line 720
(https://github.com/git/git/blob/master/configure.ac#L722).

I think the test program needs to include <arpa/inet.h>. Then, if the
current -lresolv test fails, configure should use the same program and
check -lsocket -lnls.

How would you like to craft the test? Or how should I craft the test?

# The next few tests will define NEEDS_RESOLV if linking with
# libresolv provides some of the functions we would normally get
# from libc.
NEEDS_RESOLV=
#
# Define NO_INET_NTOP if linking with -lresolv is not enough.
# Solaris 2.7 in particular hos inet_ntop in -lresolv.
NO_INET_NTOP=
AC_CHECK_FUNC([inet_ntop],
[],
[AC_CHECK_LIB([resolv], [inet_ntop],
[NEEDS_RESOLV=YesPlease],
[NO_INET_NTOP=YesPlease])
])
GIT_CONF_SUBST([NO_INET_NTOP])

Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’

[Jeff King]

On Mon, Feb 03, 2020 at 05:46:53AM -0500, Jeffrey Walton wrote:

> Below is from configure.ac around line 720
> (https://github.com/git/git/blob/master/configure.ac#L722).
> 
> I think the test program needs to include <arpa/inet.h>.

I don't know very much about autoconf, but I'm not sure we need to worry
about the header. Looking at the generated "configure" script, I think
it puts in a dummy prototype, and just confirms that the linker is able
to find it (the resulting test-program would obviously behave poorly,
but we don't try to run it).

> Then, if the current -lresolv test fails, configure should use the
> same program and check -lsocket -lnls.

Yeah, that makes sense. Though there is a test above for -lsocket, and
if it works, then we put "-lsocket" into $LIBS in the configure script.
And I _think_ that means that subsequent tests would already be trying
with -lsocket, and we might just need a similar test for -lnsl (but
again, my autoconf is quite rusty).

You might get more information by looking at the output in config.log to
see the actual compiler/linker output during the inet_ntop test, and why
the link fails.

-Peff