Project does not compile with libnds v2 or later

[Lanlost]

TWiLight Menu++ Version: nightly

Building in Windows via. Docker image. (compile_docker.ps1)

Expected behavior

Project should build.

Actual behavior

Build fails with error.

Steps to reproduce

1. git clone --recursive https://github.com/DS-Homebrew/TWiLightMenu.git
2. cd TWiLightMenu
3. .\compile_docker.ps1 clean
4. .\compile_docker.ps1 package

Note: I get the EXACT same output if I install DevKitPro, install everything, and build locally with "make clean" and "make package" natively using Windows.

Notes

Here is the output:

PS S:\Projects\GitHub\TWiLightMenu> .\compile_docker.ps1 package
Docker version 26.1.1, build 4cf5afa
make[1]: Entering directory '/data/universal/libnds32'
mkdir lib
make -C arm9 BUILD=release || { exit 1;}
make[2]: Entering directory '/data/universal/libnds32/arm9'
default_font.bin
grit /data/universal/libnds32/arm9/../source/arm9/gfx/keyboardGfx.png -fts -okeyboardGfx
STATUS: ---grit v0.9.2 ---
STATUS: Individual runs.
STATUS: Input file /data/universal/libnds32/arm9/../source/arm9/gfx/keyboardGfx.png
WARNING: No main mode specified (-gt/-gb).
STATUS: Output file: 'keyboardGfx'.
STATUS: Started run at: 2024-12-05, 17:55:51
STATUS: Validating gr.
WARNING: No explicit symbol name. In overwrite mode, so using dst title.
STATUS: Validation succeeded.
STATUS: Preparing data.
STATUS: Work-DIB creation.
STATUS: Work-DIB creation complete: 256x320@8.
STATUS: Performing tile reduction: unique tiles; flip;
STATUS: Map preparation complete.
STATUS: Graphics preparation.
STATUS: Bitpacking: 8 -> 4.
STATUS: Compressing: 01
STATUS: Graphics preparation complete.
STATUS: Palette preparation.
STATUS: Palette preparation complete.
STATUS: Data preparation complete.
STATUS: Export to GNU asm: keyboardGfx into keyboardGfx.s .
STATUS: Run completed :).
STATUS: Done!
keyboardGfx.s
background.c

...

make[2]: Leaving directory '/data/universal/libnds32/arm7'
make[1]: Leaving directory '/data/universal/libnds32'
make[1]: Entering directory '/data/booter'
make[2]: Entering directory '/data/booter/bootloader'
make[3]: Entering directory '/data/booter/bootloader/build'
arm9clear.arm.c
boot.c
In file included from /opt/devkitpro/libnds/include/nds/ndstypes.h:36,
from /data/booter/bootloader/source/boot.c:36:
/opt/devkitpro/libnds/include/nds/arm9/video.h: In function 'vramSetBankA':
/opt/devkitpro/calico/include/calico/nds/arm9/vram.h:19:34: error: 'IO_VRAMCNT_A' undeclared (first use in this function); did you mean 'REG_VRAMCNT_A'?
19 | #define REG_VRAMCNT_A MK_REG(u8, IO_VRAMCNT_A)
| ^~~~~~~~~~~~
...

make[3]: *** [/opt/devkitpro/devkitARM/base_rules:40: boot.o] Error 1
make[3]: Leaving directory '/data/booter/bootloader/build'
make[2]: *** [Makefile:88: build] Error 2
make[2]: Leaving directory '/data/booter/bootloader'
make[1]: *** [Makefile:198: bootloader] Error 2
make[1]: Leaving directory '/data/booter'
make: *** [Makefile:17: package] Error 2

If I open up the source in VSCode I can see the definition of "IO_VRAMCNT_A", but it's only defined if building arm9. Shouldn't this already be the case? On the 5th line I see "make -C arm9 BUILD=release" Shouldn't EVERYTHING be building this way?

See attachment for full build log.

Build.log

[Lanlost]

Okay, so it seems like universal/libnds32 is a reference to an older version of libnds32.

The problem is that devkitpro will install a newer version, and the make file here never installs the referenced version.

Inside the main TWiLightMenu makefile this can be fixed by adding the line:
@$(MAKE) -C universal/libnds32 install

After building universal/libnds32 release. For example:

package:
@$(MAKE) -C universal/libnds32 release
@$(MAKE) -C universal/libnds32 install <---
@$(MAKE) -C booter dist
@$(MAKE) -C booter_fc dist
@$(MAKE) -C 3dssplash dist
...

This gets rid of the original problem I submitted this bug report for. However, this isn't the end of the problems. I now get to

make[3]: Entering directory '/s/Projects/GitHub/TWiLightMenu/booter/arm7/build'
linking booter.elf
S:/tools/coding/devkitPro/devkitARM/bin/../lib/gcc/arm-none-eabi/14.2.0/../../../../arm-none-eabi/bin/ld.exe: S:/tools/coding/devkitPro/libnds/lib\libnds7.a(interruptDispatcher.o): in function IntrRet': S:/Projects/GitHub/TWiLightMenu/universal/libnds32/source/common/interruptDispatcher.s:63:(.text+0xe4): undefined reference to __irq_flagsaux'
collect2.exe: error: ld returned 1 exit status
make[3]: *** [/opt/devkitpro/devkitARM/ds_rules:61: /s/Projects/GitHub/TWiLightMenu/booter/arm7/booter.elf] Error 1

So I guess I need to know what version of devkitpro people are using, or what versions of the packages.

I'm assuming people have updated the TWiLightMenu source and never updated their packages for devkitpro so people who are able to build aren't even aware this is an issue.

I really hate it because I really want to do some work on this project. If anyone has any suggestions please let me know.

[NightScript370]

Unfortunately, libnds v2 (aka calico) changed a lot of internal code we relied on, breaking our usage of it. We were forced to pin it back to pre-update.

Our eventual plan would be a migration to BlocksDS IIRC, but as of now, we usually tell people to use the old docker version, pinned in the GitHub Actions

[Lanlost]

You are correct.

I was able to the "FROM" line in the dockerfile to be:
FROM devkitpro/devkitarm:20241104

And it's building!

Should I make the change and make a pull request for it? Or possibly update the instructions to mention making this change for now? It would be incredibly helpful for anyone trying to make contributions.

[lifehackerhansol]

Feel free to PR, or I can do it when I remember to.

The devkitARM update is unlikely to be fixed soon if at all.

[lifehackerhansol]

I've updated the Dockerfile. But this should stay open until some solution for the toolchain issue is solved.