Toolchain expects the sysroot to end with a "w64devkit" directory (missing includes when renamed)

[NSP-0123456]

I tried to build latest commit b061793 on windows 11 x64.

gcc seems to be broken.
A simple code like

#include <stdio.h>
#include <stdarg.h>

/* print all non-negative args one at a time;
   all args are assumed to be of int type */
void printargs(int arg1, ...)
{
  va_list ap;
  int i;

  va_start(ap, arg1); 
  for (i = arg1; i >= 0; i = va_arg(ap, int))
    printf("%d ", i);
  va_end(ap);
  putchar('\n');
}

int main(void)
{
   printargs(5, 2, 14, 84, 97, 15, 24, 48, -1);
   printargs(84, 51, -1);
   printargs(-1);
   printargs(1, -1);
   return 0;
}

fails to compile
stdsample.c:1:10: fatal error: stdio.h: No such file or directory.

If i add the include folder using -I /include option it works but standard includes should be found automatically.

It is also th same from the w64devkit.exe shell.

All was working fine with 2.1.0 x64 exe

[skeeto]

Thank you for testing this, and regardless this will be a lesson on what might go wrong.

Did you perhaps unpack it overtop an old version, or perhaps you have an older w64devkit on your PATH? I eliminated a component of the sysroot (3a38668), which involved modifying GCC's source code. So GCC from an older w64dk will be lost if it sees the newer layout. I'm always dogfooding and I personally only run w64dk from the latest commit, and it's been working fine.

[NSP-0123456]

I found the issue !
This is not due to old file in path but the path by itself.

• If i keep root folder name as w64devkit wherever it is located, this is working fine.
• If i rename to 2.2.0 or current the issue appear. As i installed with scoop, i always have w64devkit\version.Nr as pgm folder and a link to a current folder.
• %scoop%\apps\w64devkit\current\bin is in the path and includes are not found. If %scoop%\apps\w64devkit\w64devkit\bin is in the path all is working fine.

[skeeto]

Thanks, this is informative and helpful, and I can reproduce it. I had tested renaming the root directory, but I always had a "w64devkit" next to it, and I see now the renamed version was using that instead, so I didn't notice it was broken. I'll need to either back out the sysroot flattening or fix GCC, the main difficulty of which is just finding where. It seems to latch onto the last path component, and only the last path component, when searching for the sysroot. Before it was the architecture triple, but now it's "/w64devkit". GCC itself hardcodes it as "mingw" which I've had to hack out in a couple of places.

[sergeevabc]

Re: @NSP-0123456

Thank you for the hint!
I renamed C32 folder back to w64devkit and GCC compiles without stdio.h error.

[skeeto]

I stopped dragging my feet about importing and testing a patch to address this, an I think this issue is fixed in ff4bb19. I'd like to get more testing in before closing this issue.

[NSP-0123456]

I confirm that the issue is fixed now.

[skeeto]

Thanks for confirming, @NSP-0123456!