Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

_wfopen missing from mingw64

Started by prissi, December 02, 2019, 02:28:03 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Since my old computer broke, I had to resetup mingw64 for release. But now I cannot compile Simutrans any more. Hence, I cannot release the new version, since I fail to compile the exe by mingw64. In the function _wfopen is complained as missing by gcc. No combination of flag etc I tried could convince the compiler otherwise. But with it, no japanese supporting version can be built.


Strange. My mingw64 has _wfopen. I updated it just a few days ago.


I just tried to run a build (the first in a long time), and apart from a very long list of warnings due to lack of,19316.0.html, it compiles and runs fine. GCC 9.2.0 and mingw64 headers 8.0.0.

64-bit compilation doesn't work anymore with default C++ standard due to casting of pointers to longs, which are only 32-bit on Windows.


Those casts are only one way. since these casts are used as hashes. That should work fine. Otherwise this would have crashed a very long time ago, since long is 32 bit on MSVC anyway.

Also those stupid warning are because older gcc had a bug which silently generated wrong code. Newer version, which do the right thing, instead emit this stupid warning. "Dno-deprecated-copy" removes this junk. (Also someone added "-Wextra" to the Makefile, so to have GCC extra verbose. Seeing this, I will not submit any GCC specific warning removal patches, if one does not want to see all that stuff, than one should not ask for it in the first place.)


Quote from: prissi on December 03, 2019, 01:13:32 AMAlso someone added "-Wextra" to the Makefile, so to have GCC extra verbose
According to the GCC documentation, -Wextra is just a more descriptive name for -W which has been in the code base since forever (>10 years).


Ok, I found a discussion on a mailing list, that -Wextra gives more warnings. But as it may, for the problem in case silencing the warning may be the best option because it is rather not a problem in recent GCC or any other compiler.

And I could solve the problem: Aparently there was an old mingw-1.0 on drive D, which libraries were linked. Renaming that folder did solve my issue. So there will be a release tonight.