{"thread":{"id":"52732","subject":"git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’","startedAt":"2020-02-01T11:39:37Z","lastAt":"2020-02-03T11:02:52Z","messageCount":8,"participants":["Jeffrey Walton","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"390990","messageId":"CAH8yC8m3JFvEcfFF3z1rrRnEPK-adHGObmkOhNZiph7QJKUWqA@mail.gmail.com","threadId":"52732","inReplyTo":null,"subject":"git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’","fromName":"Jeffrey Walton","fromEmail":"noloader@gmail.com","sentAt":"2020-02-01T11:39:24Z","receivedAt":"2020-02-01T11:39:37Z","isPatch":false,"sender":{"key":"noloader@gmail.com","avatar":null},"body":"Hi Everyone,\n\nI'm building the 2.25 release tarball on Solaris 11.3 i86pc. I'm\ncatching an error:\n\n$ gmake\n CC fuzz-commit-graph.o\nIn file included from commit-graph.h:4:0,\n from fuzz-commit-graph.c:1:\ngit-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’\n const char *inet_ntop(int af, const void *src, char *dst, size_t size);\n ^\nIn file included from git-compat-util.h:226:0,\n from commit-graph.h:4,\n from fuzz-commit-graph.c:1:\n/usr/include/arpa/inet.h:43:20: note: previous declaration of\n‘inet_ntop’ was here\n extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,\n ^\ngmake: *** [fuzz-commit-graph.o] Error 1\n\nAnd:\n\n$ cat -n /usr/include/arpa/inet.h\n...\n 41 #if !defined(_XPG4_2) || defined(_XPG6) || defined(__EXTENSIONS__)\n 42 extern int inet_pton(int, const char *_RESTRICT_KYWD, void\n*_RESTRICT_KYWD);\n 43 extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,\n 44 char *_RESTRICT_KYWD, socklen_t);\n 45 #endif /* !defined(_XPG4_2) || defined(_XPG6) ||\ndefined(__EXTENSIONS__) */\n\nJeff\n"},{"id":"390991","messageId":"CAH8yC8mh0gysNz3Dbrph0f8KZ8DEWaH-6rWg6fSOD-_aGh3=3A@mail.gmail.com","threadId":"52732","inReplyTo":"CAH8yC8m3JFvEcfFF3z1rrRnEPK-adHGObmkOhNZiph7QJKUWqA@mail.gmail.com","subject":"Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’","fromName":"Jeffrey Walton","fromEmail":"noloader@gmail.com","sentAt":"2020-02-01T12:12:21Z","receivedAt":"2020-02-01T12:12:47Z","isPatch":false,"sender":{"key":"noloader@gmail.com","avatar":null},"body":"On Sat, Feb 1, 2020 at 6:39 AM Jeffrey Walton wrote:\n>\n> I'm building the 2.25 release tarball on Solaris 11.3 i86pc. I'm\n> catching an error:\n>\n> $ gmake\n> CC fuzz-commit-graph.o\n> In file included from commit-graph.h:4:0,\n> from fuzz-commit-graph.c:1:\n> git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’\n> const char *inet_ntop(int af, const void *src, char *dst, size_t size);\n> ^\n> In file included from git-compat-util.h:226:0,\n> from commit-graph.h:4,\n> from fuzz-commit-graph.c:1:\n> /usr/include/arpa/inet.h:43:20: note: previous declaration of\n> ‘inet_ntop’ was here\n> extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,\n> ^\n> gmake: *** [fuzz-commit-graph.o] Error 1\n>\n> And:\n>\n> $ cat -n /usr/include/arpa/inet.h\n> ...\n> 41 #if !defined(_XPG4_2) || defined(_XPG6) || defined(__EXTENSIONS__)\n> 42 extern int inet_pton(int, const char *_RESTRICT_KYWD, void\n> *_RESTRICT_KYWD);\n> 43 extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,\n> 44 char *_RESTRICT_KYWD, socklen_t);\n> 45 #endif /* !defined(_XPG4_2) || defined(_XPG6) ||\n> defined(__EXTENSIONS__) */\n\nAccording to Sun's man pages:\n\ninet(3SOCKET) Sockets Library Functions inet(3SOCKET)\n\nNAME\n inet, inet6, inet_ntop, inet_pton, inet_aton, inet_addr, inet_network,\n inet_makeaddr, inet_lnaof, inet_netof, inet_ntoa - Internet address\n manipulation\n\nSYNOPSIS\n cc [ flag... ] file... -lsocket -lnsl [ library... ]\n #include \n #include \n #include \n\nMaybe the include should be on Sun systems?\n\nI was able to hack around it with the following after configure:\n\n # Solaris 11.3 work-around. The OS has inet_ntop and inet_pton\n for file in $(find \"$PWD\" -name 'Makefile')\n do\n sed '/ifdef NO_INET_NTOP/,+3 d' \"$file\" > \"$file.fixed\"\n mv \"$file.fixed\" \"$file\"\n sed '/ifdef NO_INET_PTON/,+3 d' \"$file\" > \"$file.fixed\"\n mv \"$file.fixed\" \"$file\"\n done\n\nJeff\n"},{"id":"390992","messageId":"CAH8yC8noefVsnK1cGipub3vmpq0iK3bwJDaWbiaFhJGGtNzHWw@mail.gmail.com","threadId":"52732","inReplyTo":"CAH8yC8mh0gysNz3Dbrph0f8KZ8DEWaH-6rWg6fSOD-_aGh3=3A@mail.gmail.com","subject":"Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’","fromName":"Jeffrey Walton","fromEmail":"noloader@gmail.com","sentAt":"2020-02-01T12:34:03Z","receivedAt":"2020-02-01T12:34:17Z","isPatch":false,"sender":{"key":"noloader@gmail.com","avatar":null},"body":"On Sat, Feb 1, 2020 at 7:12 AM Jeffrey Walton wrote:\n>\n> On Sat, Feb 1, 2020 at 6:39 AM Jeffrey Walton wrote:\n> >\n> > I'm building the 2.25 release tarball on Solaris 11.3 i86pc. I'm\n> > catching an error:\n> >\n> > $ gmake\n> > CC fuzz-commit-graph.o\n> > In file included from commit-graph.h:4:0,\n> > from fuzz-commit-graph.c:1:\n> > git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’\n> > const char *inet_ntop(int af, const void *src, char *dst, size_t size);\n> > ^\n> > In file included from git-compat-util.h:226:0,\n> > from commit-graph.h:4,\n> > from fuzz-commit-graph.c:1:\n> > /usr/include/arpa/inet.h:43:20: note: previous declaration of\n> > ‘inet_ntop’ was here\n> > extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,\n> > ^\n> > gmake: *** [fuzz-commit-graph.o] Error 1\n> >\n> > And:\n> >\n> > $ cat -n /usr/include/arpa/inet.h\n> > ...\n> > 41 #if !defined(_XPG4_2) || defined(_XPG6) || defined(__EXTENSIONS__)\n> > 42 extern int inet_pton(int, const char *_RESTRICT_KYWD, void\n> > *_RESTRICT_KYWD);\n> > 43 extern const char *inet_ntop(int, const void *_RESTRICT_KYWD,\n> > 44 char *_RESTRICT_KYWD, socklen_t);\n> > 45 #endif /* !defined(_XPG4_2) || defined(_XPG6) ||\n> > defined(__EXTENSIONS__) */\n>\n> According to Sun's man pages:\n>\n> inet(3SOCKET) Sockets Library Functions inet(3SOCKET)\n>\n> NAME\n> inet, inet6, inet_ntop, inet_pton, inet_aton, inet_addr, inet_network,\n> inet_makeaddr, inet_lnaof, inet_netof, inet_ntoa - Internet address\n> manipulation\n>\n> SYNOPSIS\n> cc [ flag... ] file... -lsocket -lnsl [ library... ]\n> #include \n> #include \n> #include \n>\n> Maybe the include should be on Sun systems?\n\nThis may be part of the issue, too.\n\n checking for socket in -lc... no\n checking for inet_ntop... no\n checking for inet_ntop in -lresolv... no\n checking for inet_pton... no\n checking for inet_pton in -lresolv... no\n\n-lsocket -lnsl should probably be tested.\n\nJeff\n"},{"id":"391028","messageId":"20200203085405.GC2164@coredump.intra.peff.net","threadId":"52732","inReplyTo":"CAH8yC8mh0gysNz3Dbrph0f8KZ8DEWaH-6rWg6fSOD-_aGh3=3A@mail.gmail.com","subject":"Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-02-03T08:54:05Z","receivedAt":"2020-02-03T08:54:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 01, 2020 at 07:12:21AM -0500, Jeffrey Walton wrote:\n\n> Maybe the include should be on Sun systems?\n\nIt is included already. I think the real problem is that we are\ndeclaring our own replacement inet_ntop(), which then conflicts with the\nsystem one.\n\n> I was able to hack around it with the following after configure:\n> \n> # Solaris 11.3 work-around. The OS has inet_ntop and inet_pton\n> for file in $(find \"$PWD\" -name 'Makefile')\n> do\n> sed '/ifdef NO_INET_NTOP/,+3 d' \"$file\" > \"$file.fixed\"\n> mv \"$file.fixed\" \"$file\"\n> sed '/ifdef NO_INET_PTON/,+3 d' \"$file\" > \"$file.fixed\"\n> mv \"$file.fixed\" \"$file\"\n> done\n\nAs you found there's a knob for this already. Building with:\n\n make NO_INET_NTOP= NO_INET_PTON=\n\nto clear those flags would probably work (as would putting those\nvariables in your config.mak file).\n\nBut having those variables unset is already the default. The root of the\nproblem is likely that the autoconf test seems to get the wrong result\non Solaris (another workaround would be to remove them from\nconfig.mak.autogen, but that will get obliterated next time you run\n./configure).\n\nThe real fix would be teaching configure.ac to check for the correct\nlibraries (it looks like it has a -lsocket test already; I'm not sure if\nthat isn't being used in the test-compile for inet_ntop(), or if we need\nto also be adding libraries like -lnsl).\n\nI suspect that running autoconf with CFLAGS='-lsocket -lnsl' in the\nenvironment might also make the problem go away, but it's been a long\nenough time since I touched anything related to autoconf that I'm not\nsure.\n\nThis also seems eerily familiar:\n\n https://lore.kernel.org/git/CAH8yC8kOj5a5PN4V7mj7xZPoNDr-MH-CkirxRKyfx1-qAvfpqQ@mail.gmail.com/\n\n:) I second Junio's notion there that you may be better off skipping\n./configure entirely.\n\n-Peff\n"},{"id":"391030","messageId":"CAH8yC8=_9OtBJ2dMJPSGb3bYf-b+C6GYXx+NP4Dy_LDCoiks+A@mail.gmail.com","threadId":"52732","inReplyTo":"20200203085405.GC2164@coredump.intra.peff.net","subject":"Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’","fromName":"Jeffrey Walton","fromEmail":"noloader@gmail.com","sentAt":"2020-02-03T08:59:19Z","receivedAt":"2020-02-03T08:59:34Z","isPatch":false,"sender":{"key":"noloader@gmail.com","avatar":null},"body":"On Mon, Feb 3, 2020 at 3:54 AM Jeff King wrote:\n>\n> On Sat, Feb 01, 2020 at 07:12:21AM -0500, Jeffrey Walton wrote:\n>\n> > Maybe the include should be on Sun systems?\n> ...\n> This also seems eerily familiar:\n>\n> https://lore.kernel.org/git/CAH8yC8kOj5a5PN4V7mj7xZPoNDr-MH-CkirxRKyfx1-qAvfpqQ@mail.gmail.com/\n>\n> :) I second Junio's notion there that you may be better off skipping\n> ./configure entirely.Thanks Jeff.\n\nI run 'make configure' and configure because that's what the INSTALL\ntells me to do.\n\nForgive my ignorance... If I don't run configure, then how do I\nconfigure things?\n\nJeff\n"},{"id":"391031","messageId":"20200203100108.GA1072975@coredump.intra.peff.net","threadId":"52732","inReplyTo":"CAH8yC8=_9OtBJ2dMJPSGb3bYf-b+C6GYXx+NP4Dy_LDCoiks+A@mail.gmail.com","subject":"Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-02-03T10:01:08Z","receivedAt":"2020-02-03T10:01:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 03, 2020 at 03:59:19AM -0500, Jeffrey Walton wrote:\n\n> > :) I second Junio's notion there that you may be better off skipping\n> > ./configure entirely.Thanks Jeff.\n> \n> I run 'make configure' and configure because that's what the INSTALL\n> tells me to do.\n> \n> Forgive my ignorance... If I don't run configure, then how do I\n> configure things?\n\nAbove the \"Alternatively you can use autoconf...\" in INSTALL, there is:\n\n The beginning of the Makefile documents many variables that affect the\n way git is built. You can override them either from the command line,\n or in a config.mak file.\n\nYou often don't need to set most of those flags, because\nconfig.mak.uname picks some defaults based on the platform we find via\n\"uname\".\n\nSo I'd first just try \"make\" without any config. If that doesn't work\nout of the box, a patch to update config.mak.uname would be welcome.\n\nIf \"./configure && make\" also doesn't work, certainly patches are\nwelcome there, too. The reason I say you may be better off skipping it\nis that historically it seems to not be kept as up-to-date. Usually it\nwould not make things _worse_ to run it, but in this inet_ntop case, I\nthink it does.\n\n-Peff\n"},{"id":"391033","messageId":"CAH8yC8mmNXGw13zkrmxxJFQKEsmGqkKHFp13+U7==umHM2WR_Q@mail.gmail.com","threadId":"52732","inReplyTo":"20200203085405.GC2164@coredump.intra.peff.net","subject":"Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’","fromName":"Jeffrey Walton","fromEmail":"noloader@gmail.com","sentAt":"2020-02-03T10:46:53Z","receivedAt":"2020-02-03T10:48:13Z","isPatch":false,"sender":{"key":"noloader@gmail.com","avatar":null},"body":"...\n> But having those variables unset is already the default. The root of the\n> problem is likely that the autoconf test seems to get the wrong result\n> on Solaris (another workaround would be to remove them from\n> config.mak.autogen, but that will get obliterated next time you run\n> ./configure).\n\nThanks Jeff.\n\nBelow is from configure.ac around line 720\n(https://github.com/git/git/blob/master/configure.ac#L722).\n\nI think the test program needs to include . Then, if the\ncurrent -lresolv test fails, configure should use the same program and\ncheck -lsocket -lnls.\n\nHow would you like to craft the test? Or how should I craft the test?\n\n# The next few tests will define NEEDS_RESOLV if linking with\n# libresolv provides some of the functions we would normally get\n# from libc.\nNEEDS_RESOLV=\n#\n# Define NO_INET_NTOP if linking with -lresolv is not enough.\n# Solaris 2.7 in particular hos inet_ntop in -lresolv.\nNO_INET_NTOP=\nAC_CHECK_FUNC([inet_ntop],\n[],\n[AC_CHECK_LIB([resolv], [inet_ntop],\n[NEEDS_RESOLV=YesPlease],\n[NO_INET_NTOP=YesPlease])\n])\nGIT_CONF_SUBST([NO_INET_NTOP])\n"},{"id":"391035","messageId":"20200203110249.GA4153124@coredump.intra.peff.net","threadId":"52732","inReplyTo":"CAH8yC8mmNXGw13zkrmxxJFQKEsmGqkKHFp13+U7==umHM2WR_Q@mail.gmail.com","subject":"Re: git-compat-util.h:798:13: error: conflicting types for ‘inet_ntop’","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-02-03T11:02:49Z","receivedAt":"2020-02-03T11:02:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 03, 2020 at 05:46:53AM -0500, Jeffrey Walton wrote:\n\n> Below is from configure.ac around line 720\n> (https://github.com/git/git/blob/master/configure.ac#L722).\n> \n> I think the test program needs to include .\n\nI don't know very much about autoconf, but I'm not sure we need to worry\nabout the header. Looking at the generated \"configure\" script, I think\nit puts in a dummy prototype, and just confirms that the linker is able\nto find it (the resulting test-program would obviously behave poorly,\nbut we don't try to run it).\n\n> Then, if the current -lresolv test fails, configure should use the\n> same program and check -lsocket -lnls.\n\nYeah, that makes sense. Though there is a test above for -lsocket, and\nif it works, then we put \"-lsocket\" into $LIBS in the configure script.\nAnd I _think_ that means that subsequent tests would already be trying\nwith -lsocket, and we might just need a similar test for -lnsl (but\nagain, my autoconf is quite rusty).\n\nYou might get more information by looking at the output in config.log to\nsee the actual compiler/linker output during the inet_ntop test, and why\nthe link fails.\n\n-Peff\n"}]}