Fix windows debug

[simonlegrand]

Fix of the compilation errors like:

(.pdata$_ZNK10E_F_F0_OptI6ResizeI2KNIPKN5Fem2D4MeshEEEPS6_Lb1EEclEPv+0x0): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against `.text$_ZNK10E_F_F0_OptI6ResizeI2KNIPKN5Fem2D4MeshEEEPS6_Lb1EEclEPv'

on Windows in Debug mode. According to the doc, the address space of the 'relocation section' is only 32 bits large. Since some symbols couldn't fit into this section, it led to many subsequent 'undefined reference'. Adding the "-Wa,-mbig-obj" assembler flag fixes the problem by increasing the size of the relocation section.
There are still errors during the 'make check' phase, but it seems a good beginning, we can debug under Windows.

I also removed unused ff_nocygwin variable

[prj-]

@simonlegrand, any plan to wrap this up soon?

[simonlegrand]

To sum up check failures:

• 3d/Poisson3d.md on Windows/sequential. An assertion fails.
• plugin/shell.edp, on both Windows/sequential and Windows/full, generates a SIGSEGV

I just returned from vacation, Ididn't have time to investigate yet. I could use some help for the assertion failure, and I'll try to get more details about the segmentation fault.

[frederichecht]

To Morrow , I go to Jussieu; I will test this, Best , Frederic.

…

Le 30 juin 2026 à 15:36, slegrand ***@***.***> a écrit : simonlegrand left a comment (FreeFem/FreeFem-sources#398) <#398 (comment)> To sum up check failures: 3d/Poisson3d.md on Windows/sequential. An assertion fails. plugin/shell.edp, on both Windows/sequential and Windows/full, generates a SIGSEGV I just returned from vacation, Ididn't have time to investigate yet. I could use some help for the assertion failure, and I'll try to get more details about the segmentation fault. — Reply to this email directly, view it on GitHub <#398?email_source=notifications&email_token=ABLPNDEZ2AO6URIEGWPNHXD5CO64LA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUGQYDKMRYGM32M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4844052837>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLPNDCIVCSBBHPWSG5J2JT5CO64LAVCNFSNUABFKJSXA33TNF2G64TZHMYTEMJWGE2TQMZUHNEXG43VMU5TINJVHAYDONRUGQYKC5QC>. You are receiving this because you are subscribed to this thread.

[prj-]

@simonlegrand, could you please grant me write-access to your fork?

[simonlegrand]

I found out that the call to the stat function in shell.cpp

long ff_isdir(string *c) {
  struct stat buff;
  if (0 == stat(c->c_str(), &buff)) {
    return (buff.st_mode & S_IFDIR) ? 1 : 0;
  }
  else{
    return -1;
  }
}

triggers a SIGSEV signal in on Windows/Debug. AI told me that it is a known bug in MinGW, the macro stat expands to a function (e.g., _stat64) that writes a larger struct than struct stat resolves to (e.g., struct _stat32).
I proposed an #ifdef _WIN32 solution in 008c1d6, , but I think using std::filesystem would be more robust (and modern). I implies switching to c++17. What do you think?

[prj-]

If we can stick to C++14, I think we should.