Daniel Thornburgh

Yep, but there isn't a github feature to track deps between bugs, unfortunately. Although I've recently started using the issue mention feature to track this implicitly.

Probably just aarch64; desktop OSes on arm32 is pretty darn rare these days. But we'd need separate builds on Apple M1 and AArch64 Linux. The main issue is CI; it's...

Can you provide some more information about what you're trying to do here? From the logs, it doesn't look like this issue is about the CMake build of the SDK...

Ah, I see what's going on here; yep, this is a bug, and your diagnosis is correct. I think we should probably try to set CMAKE_TRY_COMPILE_TARGET_TYPE for incomplete targets like...

The changes you have look more or less like I'd expect; I think we can hammer out the details in a PR if you're up for it.

There also needs to be a user journey for banking DPCM in e.g. MMC3. At least one user has struggled with this, and it's not clear what the constraints are.

The code to bank out the whole library also seems unnecessarily specific; there should be a praxis for this, since it's desirable to do it with all kinds of libraries,...

Downgrading to p2 now that there's a known way to do this.

Removing the dependency on llvm-mos/llvm-mos#71; our installables aren't *that* big, and it's very unlikely to make sense to partially upgrade the SDK along `.so` boundaries.

> @asiekierka I tried to use $1602 as `__basic_zp_start`. But there was an error while compiling the code: > > ``` > ld.lld: error: .//m65script.prg.lto.o:(function (anonymous namespace)::FreeChunk::insert(void*, unsigned int): .text._ZN12_GLOBAL__N_19FreeChunk6insertEPvj+0x2e):...