I am on Windows 10 and can still build for the simulator using Visual Studio.
My device build no longer works. The cmake arm command runs and populates my build folder but when running nmake I get the following errors:
c:/progra~2/armgnu~1/1213fb~1.2mp/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/progra~2/armgnu~1/1213fb~1.2mp/bin/../lib/gcc/arm-none-eabi/12.2.0/thumb/v7e-m+fp/hard\libc.a(libc_a-closer.o): in function `_close_r':
/data/jenkins/workspace/GNU-toolchain/arm-12-mpacbti/src/newlib-cygwin/newlib/libc/reent/closer.c:47: warning: _close is not implemented and will always fail
c:/progra~2/armgnu~1/1213fb~1.2mp/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/progra~2/armgnu~1/1213fb~1.2mp/bin/../lib/gcc/arm-none-eabi/12.2.0/thumb/v7e-m+fp/hard\libc.a(libc_a-lseekr.o): in function `_lseek_r':
/data/jenkins/workspace/GNU-toolchain/arm-12-mpacbti/src/newlib-cygwin/newlib/libc/reent/lseekr.c:49: warning: _lseek is not implemented and will always fail
c:/progra~2/armgnu~1/1213fb~1.2mp/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/progra~2/armgnu~1/1213fb~1.2mp/bin/../lib/gcc/arm-none-eabi/12.2.0/thumb/v7e-m+fp/hard\libc.a(libc_a-readr.o): in function `_read_r':
/data/jenkins/workspace/GNU-toolchain/arm-12-mpacbti/src/newlib-cygwin/newlib/libc/reent/readr.c:49: warning: _read is not implemented and will always fail
c:/progra~2/armgnu~1/1213fb~1.2mp/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/progra~2/armgnu~1/1213fb~1.2mp/bin/../lib/gcc/arm-none-eabi/12.2.0/thumb/v7e-m+fp/hard\libc.a(libc_a-writer.o): in function `_write_r':
/data/jenkins/workspace/GNU-toolchain/arm-12-mpacbti/src/newlib-cygwin/newlib/libc/reent/writer.c:49: warning: _write is not implemented and will always fail
c:/progra~2/armgnu~1/1213fb~1.2mp/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: warning: playdate-c-game-template_DEVICE.elf has a LOAD segment with RWX permissionsc:/progra~2/armgnu~1/1213fb~1.2mp/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/progra~2/armgnu~1/1213fb~1.2mp/bin/../lib/gcc/arm-none-eabi/12.2.0/thumb/v7e-m+fp/hard\libc.a(libc_a-fini.o): in function `__libc_fini_array':
/data/jenkins/workspace/GNU-toolchain/arm-12-mpacbti/src/newlib-cygwin/newlib/libc/misc/fini.c:36: undefined reference to `_fini'
collect2.exe: error: ld returned 1 exit status
NMAKE : fatal error U1077: 'C:\PROGRA~2\ARMGNU~1\1213FB~1.2MP\bin\AR19DD~1.EXE' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
I am using this line in my CMakeLists.txt for the "armgcc" build:
@willco noticed something odd about the SDK installer on Windows--looks like it merges the new files into an existing SDK instead of replacing them, which can leave gunk behind (namely, old pdex.bin files that shouldn't be in source folders any more). Can you try moving your current SDK folder aside by renaming it, then install a clean copy of the 2.0 SDK folder and see if that changes anything? I'm not sure what else would be causing those errors.. We didn't change the version of the ARM toolchain in 2.0.
I'll try wiping and reinstalling the SDK although I have been renaming old SDK folder versions before installing SDK updates for a while now so it should have been a clean install.
Sorry for late response to this. I was in the middle of a big feature that I wanted to complete before trying to figure the build issues out. I was able to keep using the old pdex.bin which allowed me to keep running simulator builds.
I have just deleted the old pdex.dll and pdex.bin from my "/Source" folder and added an empty main.lua into my "/Source" folder. This allowed me to run simulator builds once again without relying on the old pdex.bin.
My device build still isn't working though and still gives the same output as shown in my OP.
What is funny is that my old pre 2.0 builds do work on my Playdate device that is updated to 2.0 firmware. I am using only C/CAPI with no lua so I was curious as to what parts of the CAPI no longer work on 2.0 since all the CAPI features I've used so far, do work.
With hindsight, I should have downloaded the 2.0 beta SDK's and sorted this out back then. I will definitely be doing that in future SDK beta releases.
I have just successfully made a device build for "Sprite Game" from the SDK 2.0 CAPI Examples.
So there must be something that I am doing in my code that is preventing device build from working for my game.
Ok, ok. I figured it out. I had some debug code which had a call to exit(). This obviously pulls in a bunch of C file system stuff that is not needed/supported on device. Commenting out these calls to exit() and rerunning the device build fixes my issue.
To @lurgypai , Just check for any C calls you may have in your code that may be specific to non arm systems. assert(), exit() and srand() are common ones to look out for.
Sorry for wasting anyones time with this, I'm all good now!
Sorry for the really late update to this, been busy with work.
It was indeed an C system call, I was using sprintf for generating filenames to read. This worked before the 2.0.0 SDK, and I would appreciate not having to roll my own C standard library functions if necessary. Are C standard library functions not supported moving forward? If this is a bug I'll add a new thread reporting it as such, otherwise I'll just write my own.
Edit:
Welp, I realized I definitely did not compile it before the 2.0 SDK lol, I added it after, the addition just happened to coincide with the SDK launch. I was able to make do with just strcat and atoi. Note to self, no standard lib headers!
But adding an empty main.lua file in the source folder will work around that until we get the fix out.