![]() |
niXman gcc-13.1.0 - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11) +--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2) +--- Thread: niXman gcc-13.1.0 (/showthread.php?tid=1714) |
niXman gcc-13.1.0 - Jack - 06-02-2023 niXman has updated gcc version from 12.2.0 to 13.1.0, I tried it and so far no problems RE: niXman gcc-13.1.0 - Kernelpanic - 06-02-2023 (06-02-2023, 10:14 AM)Jack Wrote: niXman has updated gcc version from 12.2.0 to 13.1.0, I tried it and so far no problems Thanks for the hint. Now one can play around with the latest version. ![]() github - GCC for Windows or GCC and MinGW-w64 for Windows RE: niXman gcc-13.1.0 - a740g - 06-02-2023 Yeah. I am using it now. Seems good so far. I will do some more testing. Honestly though, I am more interested in mstorsjo/llvm-mingw: An LLVM/Clang/LLD based mingw-w64 toolchain (github.com) LLVM-MinGW allows one to build native binaries for ARM64 for Windows. RE: niXman gcc-13.1.0 - Jack - 06-02-2023 hi a740g wonder whether QB64pe will work with ucrt? will give it try RE: niXman gcc-13.1.0 - Jack - 06-02-2023 (06-02-2023, 04:33 PM)a740g Wrote: Yeah. I am using it now. Seems good so far. I will do some more testing. it compiles ok but there some anomalies, the mouse click is slow to register -- it takes several tries also the graphics are off RE: niXman gcc-13.1.0 - a740g - 06-03-2023 Yeah. It compiles just fine because of all the changes we have made to QB64-PE codebase (you can see these in the git commits). However, as you discovered, there are still some issues. We'll need to get these issues fixed if we ever want to make the switch. RE: niXman gcc-13.1.0 - Jack - 10-03-2023 @ a740g congratulations to all the QB64pe developers ![]() RE: niXman gcc-13.1.0 - JRace - 10-04-2023 niXman's builds are great. I just wish niXman was still building GCC versions with sjlj exception handling. Yeah, SEH is compatible with Windows DLLs, and both SEH and Dwarf are faster, but GCC with sjlj EH allows the programmer to build either 64-bit OR 32-bit executables with the same compiler. One cannot do that with an SEH or Dwarf compiler on Windows. (I've recently started putting mstorsjo's LLVM-MinGW builds (https://github.com/mstorsjo/llvm-mingw) on my software toolkit thumbdrive because it does allow both 64-bit and 32-bit compilation.) Re UCRT: UCRT is the wave of the future for Windows Run Time Library support. GCC on Windows has historically relied on MSVCRT.DLL, which is NOT officially a part of Windows (as Microsoft has long pointed out). MS does not add new features to MSVCRT.DLL, so MSVCRT has not kept up with the growth of modern C/C++. Modern compilers must provide their own library functions to fill in the gaps in MSVCRT. UCRT was introduced with Windows 10 as an official component of Windows going forward, well, at least until MS executives come up with their next brilliant plan for the future. Folks using older versions of Windows may have to download & install UCRT themselves. Surprisingly, UCRT is currently available for Windows versions going back to Vista. I say "currently" because we all know how MS prefers to abandon older Windows versions. I'm not aware of any statements from MS on the subject, but the creation of UCRT as an official part of Windows implies to me that MS may be planning to "disappear" MSVCRT in the near future. RE: niXman gcc-13.1.0 - a740g - 10-04-2023 Yeah. Those UCRT distros work just fine. We've fixed the issue with the IDE (listed earlier in this thread) and added initial native Windows on ARM64 support using LLVM-MingW. See https://github.com/QB64-Phoenix-Edition/QB64pe/blob/83a10dc877c3867a0e6dc1aebe63298d6f3b9e10/setup_mingw.cmd#L69 |