On Thu, Jan 29, 2026 at 11:50 AM Torbjorn SVENSSON
<[email protected]> wrote:
>
> Hi Andrew,
>
> Thanks for your reply.
>
> On 2026-01-29 20:24, Andrew Pinski wrote:
> > On Thu, Jan 29, 2026 at 10:39 AM Torbjörn SVENSSON
> > <[email protected]> wrote:
> >>
> >> Without this change, building with MinGW v9.0.0 or earlier gives the 
> >> follwing error:
> >>
> >> gcc/diagnostics/sarif-sink.cc:23:10: fatal error: afunix.h: No such file 
> >> or directory
> >>   #include <afunix.h>
> >>            ^~~~~~~~~~
> >> compilation terminated.
> >> Makefile:1219: recipe for target 'diagnostics/sarif-sink.o' failed
> >> make[1]: *** [diagnostics/sarif-sink.o] Error 1
> >>
> >>
> >> Ok for trunk?
> >>
> >> --
> >>
> >> afunix.h was first included in MinGW 10.0.0.  For earlier versions, fall
> >> back to internal definition.
> > This structure is not defined anywhere in older versions of mingw?
>
> No, there does not appear to be any other file defining this structure.
> The struct was added in 
> https://github.com/mingw-w64/mingw-w64/commit/db6335b844ed0d1d3daa034af1e724d46be6c86d
>
> > Maybe we should put this in definition in a header file that gets included.
> > So something like:
> > ```
> > #if (__MINGW64_VERSION_MAJOR - 0) >= 10
> > #include <afunix.h>
> > #endif
> > #include "mingw-workarounds.h"
> > ```
> >
> > And then inside mingw-workarounds.h define the struct for
> > `(__MINGW64_VERSION_MAJOR - 0) < 10`.
> > or something to that effect.
> >
>
> We could do that if that's considered a better solution.
> Where do you want this mingw-workarounds.h file to be located?
>
> I suppose there is another alternative to have the function 
> maybe_open_sarif_sink_for_socket() always fail for MinGW <10 by adding the 
> #if-block around the usage of the sockaddr_un type.
>
> Let me know what I should do to land a fix for older MinGW toolchains.

Both works for me but I am not sure which way is better. For our users
having the workaround is definitely better. But cleanliness of the
code having it disabled is better. Maybe folks with more mingw
knowledge than me can say if requiring a new enough mingw is ok here
or not?
I suspect yes since this is more for a new feature of diagnostic to
IDEs (or IDE like programs) and people on older mingw are less likely
to use this feature.
But I am not sure.

Thanks,
Andrew

>
> Kind regards,
> Torbjörn
>
> > Thanks,
> > Andrew Pinski
> >
> >>
> >> gcc/ChangeLog:
> >>
> >>          * diagnostics/sarif-sink.cc: Conditionally include afunix.h
> >>            depending on MinGW version used.
> >>
> >> Signed-off-by: Torbjörn SVENSSON <[email protected]>
> >> ---
> >>   gcc/diagnostics/sarif-sink.cc | 7 +++++++
> >>   1 file changed, 7 insertions(+)
> >>
> >> diff --git a/gcc/diagnostics/sarif-sink.cc b/gcc/diagnostics/sarif-sink.cc
> >> index 78743df7f1d..d4b8c77f8b8 100644
> >> --- a/gcc/diagnostics/sarif-sink.cc
> >> +++ b/gcc/diagnostics/sarif-sink.cc
> >> @@ -20,8 +20,15 @@ along with GCC; see the file COPYING3.  If not see
> >>
> >>   #ifdef __MINGW32__
> >>   #include <winsock2.h>
> >> +#if (__MINGW64_VERSION_MAJOR - 0) >= 10
> >>   #include <afunix.h>
> >>   #else
> >> +struct sockaddr_un {
> >> +  ADDRESS_FAMILY sun_family;
> >> +  char sun_path[108];
> >> +};
> >> +#endif
> >> +#else
> >>   #include <sys/un.h>
> >>   #include <sys/socket.h>
> >>   #endif
> >> --
> >> 2.43.0
> >>
>

Reply via email to