[Re-sending as I've noticed that the mailing list was dropped.] On Mon, Oct 21, 2024 at 02:08:50AM -0700, Freya Starshade wrote: Please note that we tend to not top-post on this mailing list :) > On 10/21/2024 01:56, Patrick Steinhardt wrote: > > On Sun, Oct 20, 2024 at 10:56:11PM -0700, Freya Starshade wrote: > > > Hi, > > > > > > > > > Reporting a build failure on version 2.47.0 of git, grabbed from the > > > official sources. Our environment is: > > > > > > > > > Compiler: gcc (GCC) 9.5.0 > > > > > > Linker: GNU ld (GNU Binutils) 2.43 > > > > > > Target machine triplet: SPARC64-SUN-SOLARIS2.10 > > > > > > Target machine hardware: Sun Blade 150 UltraSPARC IIe workstation > > > > > > Target OS: SunOS 5.10 Generic_150400-59 sparc SUNW,Sun-Blade-100 Solaris Sun > > > Microsystems SunOS 5.10 Generic_150400-59 PATCH January 2018 > > > > > > After running ./configure, which succeeds, running `make all` gives: > > > > > > > > > root@iris:/usr/src/depot/progress/git-2.47.0# make all > > > CC daemon.o > > > In file included from daemon.c:3: > > > git-compat-util.h:1012:13: error: conflicting types for 'inet_ntop' > > > 1012 | const char *inet_ntop(int af, const void *src, char *dst, size_t > > > size); > > > | ^~~~~~~~~ > > > In file included from git-compat-util.h:314, > > > from daemon.c:3: > > > /usr/include/arpa/inet.h:68:20: note: previous declaration of 'inet_ntop' > > > was here > > > 68 | extern const char *inet_ntop(int, const void *_RESTRICT_KYWD, > > > | ^~~~~~~~~ > > > make: *** [Makefile:2795: daemon.o] Error 1 > > > root@iris:/usr/src/depot/progress/git-2.47.0# > > > > > > > > > Anyone know what's going on here? > > Could you maybe also send the output of `./configure`? We do have a > > check in "configure.ac" that tries to find out whether your system has > > `inet_ntop()` or not. Maybe it is misdetecting the availability of that > > function on your platform and thus declares the `NO_INET_NTOP` variable, > > which causes us to pull in compat code. > > > > Out of curiosity, did you try running `make` without first running > > `./configure`? Many platforms should work alright without having to run > > autoconf first, but given that your platform is a more on the esoteric > > side I wouldn't be surprised if things didn't work there. [snip] > checking for inet_ntop... no > checking for inet_ntop in -lresolv... no > checking for inet_pton... no > checking for inet_pton in -lresolv... no So yes, indeed, your `inet_ntop()` isn't detected. Does that function require any additional libraries on your platform? Searching for this on the internet quickly brings me to... a [thread] from our own mailing list. Looks like that patch never landed. [thread]: https://lore.kernel.org/git/CAH8yC8kaWXbN+RYMJnM9em7KKW54+N07JtyS1MZk0qppD=m2BA@xxxxxxxxxxxxxx/ Patrick
