* git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’ @ 2020-02-01 11:39 Jeffrey Walton 2020-02-01 12:12 ` Jeffrey Walton 0 siblings, 1 reply; 8+ messages in thread From: Jeffrey Walton @ 2020-02-01 11:39 UTC (permalink / raw) To: Git List 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’ 2020-02-01 11:39 git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’ Jeffrey Walton @ 2020-02-01 12:12 ` Jeffrey Walton 2020-02-01 12:34 ` Jeffrey Walton 2020-02-03 8:54 ` Jeff King 0 siblings, 2 replies; 8+ messages in thread From: Jeffrey Walton @ 2020-02-01 12:12 UTC (permalink / raw) To: Git List 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’ 2020-02-01 12:12 ` Jeffrey Walton @ 2020-02-01 12:34 ` Jeffrey Walton 2020-02-03 8:54 ` Jeff King 1 sibling, 0 replies; 8+ messages in thread From: Jeffrey Walton @ 2020-02-01 12:34 UTC (permalink / raw) To: Git List 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’ 2020-02-01 12:12 ` Jeffrey Walton 2020-02-01 12:34 ` Jeffrey Walton @ 2020-02-03 8:54 ` Jeff King 2020-02-03 8:59 ` Jeffrey Walton 2020-02-03 10:46 ` Jeffrey Walton 1 sibling, 2 replies; 8+ messages in thread From: Jeff King @ 2020-02-03 8:54 UTC (permalink / raw) To: Jeffrey Walton; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’ 2020-02-03 8:54 ` Jeff King @ 2020-02-03 8:59 ` Jeffrey Walton 2020-02-03 10:01 ` Jeff King 2020-02-03 10:46 ` Jeffrey Walton 1 sibling, 1 reply; 8+ messages in thread From: Jeffrey Walton @ 2020-02-03 8:59 UTC (permalink / raw) To: Jeff King; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’ 2020-02-03 8:59 ` Jeffrey Walton @ 2020-02-03 10:01 ` Jeff King 0 siblings, 0 replies; 8+ messages in thread From: Jeff King @ 2020-02-03 10:01 UTC (permalink / raw) To: Jeffrey Walton; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’ 2020-02-03 8:54 ` Jeff King 2020-02-03 8:59 ` Jeffrey Walton @ 2020-02-03 10:46 ` Jeffrey Walton 2020-02-03 11:02 ` Jeff King 1 sibling, 1 reply; 8+ messages in thread From: Jeffrey Walton @ 2020-02-03 10:46 UTC (permalink / raw) To: Jeff King; +Cc: Git List ... > 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]) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’ 2020-02-03 10:46 ` Jeffrey Walton @ 2020-02-03 11:02 ` Jeff King 0 siblings, 0 replies; 8+ messages in thread From: Jeff King @ 2020-02-03 11:02 UTC (permalink / raw) To: Jeffrey Walton; +Cc: Git List 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-02-03 11:02 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-01 11:39 git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’ Jeffrey Walton 2020-02-01 12:12 ` Jeffrey Walton 2020-02-01 12:34 ` Jeffrey Walton 2020-02-03 8:54 ` Jeff King 2020-02-03 8:59 ` Jeffrey Walton 2020-02-03 10:01 ` Jeff King 2020-02-03 10:46 ` Jeffrey Walton 2020-02-03 11:02 ` Jeff King
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).