Greetings, Old, Oliver! >> Why don't you use the cygwin cmake?
> We want to use VS Code to work with the project. It doesn't like > Cygwin's CMake. It would also interfere with the clangd language server > since that reads from CMake's compile_commands.json which contains the > command line as it would be used within the shell. Then do not mix environments. I.e. use windows native tools with VS Code, and Cygwin with automation scripts. > I know the next question: Why are you not using a MinGW toolchain if all > you do is cross-compile for a different target anyways? > Sorry for the long paragraph. TL;DR: Management. > I didn't want to, but was forced to because, this is approximately the > reasoning I was given, "we can't prove that the Cygwin GCC toolchain and > the MinGW toolchain will produce the same code and we can't tolerate any > differences between our currently 'maintained' Cygwin toolchain and the > 'experimental and untested' MinGW toolchain". Indeed, for some reason, > the layout of the binary contents, and consequently the addresses > referencing them, differ. I'm guessing it's because of path ordering > within archives or something like that. The generated instructions, > unsurprisingly, are the same, at least for the functions I've diffed. > Nothing I said could sway my manager, so I spent a week working on this, > first having to track down a bug that livelocked GCC (it was the "Ninja > 0-byte pipe" bug, that was fixed in Cygwin 3.6.1, but our checked in > version was of course 3.6.0), then having to figure out why the command > line is interpreted weirdly and working around that (custom launcher + > undocumented CMake feature). I think I've answered the question already. -- With best regards, Andrey Repin Monday, August 4, 2025 21:49:29 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
