I would guess that mingw needs something more included to get ADDRESS_FAMILY defined?

Winsock is supposed to define ADDRESS_FAMILY, is that missing from mingw winsock includes?

/cc @vszakats

In my copy of mingw-w64-headers, ADDRESS_FAMILY is defined in winsock2.h and winsock2.h is #included by ws2tcpip.h. Though it's possible this wasn't always the case.

@LJWxyz Can you verify the above in your mingw headers?

Also, can you try with this patch applied:

diff --git a/lib/config-win32.h b/lib/config-win32.h
index 76ee6b1a7..589543ada 100644
--- a/lib/config-win32.h
+++ b/lib/config-win32.h
@@ -723,7 +723,7 @@ Vista
 #if !defined(UNIX_PATH_MAX)
   /* Replicating logic present in afunix.h of newer Windows 10 SDK versions */
 # define UNIX_PATH_MAX 108
-# include <ws2tcpip.h>
+# include <winsock2.h>
   /* !checksrc! disable TYPEDEFSTRUCT 1 */
   typedef struct sockaddr_un {
     ADDRESS_FAMILY sun_family;

yes it is included already in ws2tcpip.h

#if (defined _WINSOCK_H && !defined _WINSOCK2_H)
#error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead."
#endif

#include <winsock2.h>
#ifdef __cplusplus
extern "C" {
#endif

/**
*The IP ...

Sorry I am quite new to github and this project the snnipet is at

a/lib/config-win32.h b/lib/config-win32.h
and the changes is simply remove(-) and add(+) right?
Just to confirm.

Yeah, it's a diff format.
Means that in curl source code you should find lib/config-win32.h and few lines below line 723 replace ws2tcpip.h with winsock2.h

replaced sadly it doesn't seem to work.Could my path included unnessary binaries?

D:\Coding\C\ALLCinone>set PATH=D:\Coding\C\ALLCinone\MinGW64\mingw32\bin;D:\Coding\C\ALLCinone\MinGW64\bin;D:\Coding\C\ALLCinone\MinGW64\x86_64-w64-mingw32\bin;C:\Windows\system32;C:\Windows;....

D:\Coding\C\ALLCinone>cmd /k"set includepath=D:\Coding\C\ALLCinone\MinGW64\include"

D:\Coding\C\ALLCinone>cd F:\ProgramSetup\open source\secure\curl-7.71.1

F:\ProgramSetup\open source\secure\curl-7.71.1>mingw32-make mingw32
mingw32-make -C lib -f Makefile.m32
mingw32-make[1]: Entering directory 'F:/ProgramSetup/open source/secure/curl-7.71.1/lib'
gcc -I. -I../include -g -O2 -Wall -W -fno-strict-aliasing -m32 -DBUILDING_LIBCURL -c altsvc.c -o altsvc.o
In file included from curl_setup.h:75:0,
from altsvc.c:26:
config-win32.h:729:5: error: unknown type name 'ADDRESS_FAMILY'
ADDRESS_FAMILY sun_family;
^~~~~~~~~~~~~~
Makefile.m32:375: recipe for target 'altsvc.o' failed
mingw32-make[1]: *** [altsvc.o] Error 1
mingw32-make[1]: Leaving directory 'F:/ProgramSetup/open source/secure/curl-7.71.1/lib'
Makefile:44: recipe for target 'mingw32' failed
mingw32-make: *** [mingw32] Error 2

F:\ProgramSetup\open source\secure\curl-7.71.1>

According to the mingw-w64 repo, ADDRESS_FAMILY was added back in 2010-08-10, released likely that year or 2011 latest. (UPDATE: And there is/was an alternate timeline for the mingw/cygwin header variants.)

@LJWxyz Is it possible that you're using a mingw environment that may predate that? Can you give us some hints of the mingw version/distro you're using?

mingw-get-setup.exe ,file ver:0.603.243571
the copyright shows:2009-2013，MinGW.org project

@LJWxyz Thank you!

It's been long I had a look at the original mingw.org project, and if I followed their pointers correctly, this is their latest Win32 header package: https://osdn.net/projects/mingw/downloads/73281/w32api-5.3.4-mingw32-dev.tar.xz/, dated 2020-07-06.

Interestingly, this release doesn't define ADDRESS_FAMILY anywhere. And even though the mingw.org page states to share Win32 headers with the Cygwin project, this no longer appears to be the case, as Cygwin had switched to the mingw-w64 headers in the past and those are therefore up-to-date. I couldn't figure out where mingw.org keeps their repositories. It's possible they are still in CVS.

May I ask what is your mingw gcc version?

I have the same problem gcc 4.7.1

Thank you, so this appears to affect classic mingw and/or 10y+ old mingw-w64 environments.

One crude solution is to check for a #define committed together with ADDRESS_FAMILY typedef. One such symbol is LUP_SECURE. This method may break if an alternate header implementation adds this #define without adding the typedef, or it is has the typedef, but not the #define, Unix sockets will not be enabled automatically.

Another option is to check for !defined(__MINGW32__) || defined(__MINGW64_VERSION_MAJOR) which will enable this option on any platform except classic mingw. This will keep breaking on mingw-w64 released 10+ years ago, and on classic mingw, even if it eventually starts supporting this feature.

For the time being, and if circumstances allow it, IMO the best solution is to switch to a mingw-w64 edition from 2011 or later.

Please try this patch on various Windows platforms to see if the Unix sockets feature gets correctly enabled/disabled:

diff --git a/lib/config-win32.h b/lib/config-win32.h
index 76ee6b1a7..eeaa12655 100644
--- a/lib/config-win32.h
+++ b/lib/config-win32.h
@@ -718,18 +718,22 @@ Vista
 #define USE_WIN32_CRYPTO
 #endif
 
+/* On MinGW the ADDRESS_FAMILY typedef was committed alongside LUP_SECURE,
+   so we use it to check for the presence of the typedef. */
+#include <ws2tcpip.h>
+#if !defined(__MINGW32__) || defined(LUP_SECURE)
 /* Define to use Unix sockets. */
 #define USE_UNIX_SOCKETS
 #if !defined(UNIX_PATH_MAX)
   /* Replicating logic present in afunix.h of newer Windows 10 SDK versions */
 # define UNIX_PATH_MAX 108
-# include <ws2tcpip.h>
   /* !checksrc! disable TYPEDEFSTRUCT 1 */
   typedef struct sockaddr_un {
     ADDRESS_FAMILY sun_family;
     char sun_path[UNIX_PATH_MAX];
   } SOCKADDR_UN, *PSOCKADDR_UN;
 #endif
+#endif
 
 /* ---------------------------------------------------------------- */
 /*                       ADDITIONAL DEFINITIONS                     */

It tested OK with the latest mingw-w64.