Open godreborn opened 10 months ago
I got the main make file to work, but you can't use it at first:
It sounds like you didn't clone with submodules
It sounds like you didn't clone with submodules
actually, I had cloned recursively. I just noticed that if I compile a second time, it goes through. here's the error from the first time:
imo, this tends to suggest that when it builds that arm file, it's sometime after when it's needed to build bootstrap.nds.
Normally you'd run the root makefile without using -j or so and it should build everything
alright, thanks. that did in fact work. I don't understand why some things don't compile when using the jobs command. it's not the first time I've encountered it. I think it's simply compiling too fast or something?
I think some dependencies are not setup correctly or so. When you run single threaded it'll run in the right order.
I do like to try it with everything, considering how quick it can be to use all cpu cores. on my last computer, it took atmosphere about an hour on the dot to build with a single core. on this new laptop, 15 minutes with one core. however, with the -j command on this laptop, 3 minutes. it's insane how fast some of this stuff goes. haha
Haha yeah I should fix the dependency stuff. In any case it still works if you first build with multiple threads and then a second time with 1 thread
good luck with that, my friend. I'd be more than happy to test compiling once it's done.
I'm getting the following error when compiling, any idea what could be causing it?
$ make
make -C libs/libtwl
make[1]: Entering directory '/home/exelotl/Dev/GBARunner3/code/libs/libtwl'
make -C libtwl9
make[2]: Entering directory '/home/exelotl/Dev/GBARunner3/code/libs/libtwl/libtwl9'
make[3]: '/home/exelotl/Dev/GBARunner3/code/libs/libtwl/libtwl9/lib/libtwl9.a' is up to date.
make[2]: Leaving directory '/home/exelotl/Dev/GBARunner3/code/libs/libtwl/libtwl9'
make -C libtwl7
make[2]: Entering directory '/home/exelotl/Dev/GBARunner3/code/libs/libtwl/libtwl7'
make[3]: '/home/exelotl/Dev/GBARunner3/code/libs/libtwl/libtwl7/lib/libtwl7.a' is up to date.
make[2]: Leaving directory '/home/exelotl/Dev/GBARunner3/code/libs/libtwl/libtwl7'
make[1]: Leaving directory '/home/exelotl/Dev/GBARunner3/code/libs/libtwl'
make -C bootstrap
make[1]: Entering directory '/home/exelotl/Dev/GBARunner3/code/bootstrap'
make -C ../core/arm9
make[2]: Entering directory '/home/exelotl/Dev/GBARunner3/code/core/arm9'
linking arm9.elf
ArmDtcm.o: in function `memu_armDispatchTable':
(.dtcm+0x8): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmStmRnTable_0' defined in .dtcm section in ArmLdmStmRn.o
(.dtcm+0xa): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armStmRdTable' defined in .dtcm section in ArmLdmStmRd.o
(.dtcm+0x10): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmStmRnTable_0' defined in .dtcm section in ArmLdmStmRn.o
(.dtcm+0x12): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmRdTable' defined in .dtcm section in ArmLdmStmRd.o
(.dtcm+0x18): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmStmRnTable_1' defined in .dtcm section in ArmLdmStmRn.o
(.dtcm+0x1a): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armStmRdTable' defined in .dtcm section in ArmLdmStmRd.o
(.dtcm+0x20): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmStmRnTable_1' defined in .dtcm section in ArmLdmStmRn.o
(.dtcm+0x22): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmRdTable' defined in .dtcm section in ArmLdmStmRd.o
(.dtcm+0x28): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmStmRnTable_0' defined in .dtcm section in ArmLdmStmRn.o
(.dtcm+0x2a): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armStmRdTable' defined in .dtcm section in ArmLdmStmRd.o
(.dtcm+0x30): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[3]: *** [/opt/devkitpro/devkitARM/ds_rules:57: /home/exelotl/Dev/GBARunner3/code/core/arm9/arm9.elf] Error 1
make[2]: *** [Makefile:132: build] Error 2
make[2]: Leaving directory '/home/exelotl/Dev/GBARunner3/code/core/arm9'
make[1]: *** [Makefile:35: checkcorearm9] Error 2
make[1]: Leaving directory '/home/exelotl/Dev/GBARunner3/code/bootstrap'
make: *** [Makefile:26: checkbootstrap] Error 2
GCC version in case that helps:
$ $DEVKITARM/bin/arm-none-eabi-gcc --version
arm-none-eabi-gcc (devkitARM release 62) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
I think I read there are issues with linux not compiling.
I see some people having issues running their compile with twilight menu. I actually disabled USE_GBARUNNER2 from a 1 to a 0 in settings.ini, and I also deleted all the gbarunner2.nds from within _nds. not sure if that could cause a problem as I didn't try it without, so I only have gbarunner3 from within emulators, which could also be a problem as it's now located there for twilight menu. btw, the original build I did a few weeks ago or whenever it was had no sound. I had sound this time, and the games are working quite well from what I've seen. keep up the good work.
btw, that's before I knew I had to have the bios, so it may be unnecessary. also, btw, I was able to boot gbarunner3 on my nds lite with a flash cart. I saw it said it didn't work with the latest build of twilight menu, but it does, so I guess it was an issue with gbarunner3 originally. no issue now.
I see some people having issues running their compile with twilight menu. I actually disabled USE_GBARUNNER2 from a 1 to a 0 in settings.ini, and I also deleted all the gbarunner2.nds from within _nds. not sure if that could cause a problem as I didn't try it without, so I only have gbarunner3 from within emulators, which could also be a problem as it's now located there for twilight menu. btw, the original build I did a few weeks ago or whenever it was had no sound. I had sound this time, and the games are working quite well from what I've seen. keep up the good work.
I can confirm it's been working for me without taking these extra steps, both on a flash cart (DSTTi) and on the 3DS SD card.
btw, that's before I knew I had to have the bios, so it may be unnecessary.
Probably this, I haven't tried without BIOS present.
alright, thanks. at least I can be sure nothing is interfering. I'm not really sure how twilight menu would know which gbarunner to use unless the TEST portion of settings overrides gbarunner2.
I see some people having issues running their compile with twilight menu. I actually disabled USE_GBARUNNER2 from a 1 to a 0 in settings.ini, and I also deleted all the gbarunner2.nds from within _nds. not sure if that could cause a problem as I didn't try it without, so I only have gbarunner3 from within emulators, which could also be a problem as it's now located there for twilight menu. btw, the original build I did a few weeks ago or whenever it was had no sound. I had sound this time, and the games are working quite well from what I've seen. keep up the good work.
You don't need to replace GBARunner2 or change the settings related to it, the procedure to run GBARunner3 test builds has been stated on TwilightMenu++ latest release notes btw.
Just in case, here are the simplified steps, you need:
-TwilightMenu++ 26.1.1
or higher
-GBARunner3.nds
inside \_nds\TWiLightMenu\emulators
-GBA bios bios.bin
inside \_gba
-GBARUNNER3_TEST = 1
under the [SRLOADER]
section in \_nds\TWiLightMenu\settings.ini
This will override TwilightMenu++ default GBA loader (GBARunner2) to use GBARunner3 instead, so if you want to go back to use GBArunner2 again, you just need to set GBARUNNER3_TEST = 0
This is what I do in order to compile GBARunner3, hope it helps!
Install devkitPro Updater, only for Windows: https://github.com/devkitPro/installer/releases
Commands: git clone --recursive https://github.com/Gericom/GBARunner3.git cd GBARunner3 cd code git branch -a git checkout [insert here the branch you wanna compile] make
Like i said, this was before I knew I needed the bios. Tbh, I'm surprised I didn't have it on either ds or 3ds, because I've played gbarunner2 in the past with the same systems.
I'm having the same issue as @exelotl
ArmDtcm.o: in function `memu_armDispatchTable':
(.dtcm+0x8): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmStmRnTable_0' defined in .dtcm section in ArmLdmStmRn.o
(.dtcm+0xa): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armStmRdTable' defined in .dtcm section in ArmLdmStmRd.o
(.dtcm+0x10): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmStmRnTable_0' defined in .dtcm section in ArmLdmStmRn.o
(.dtcm+0x12): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmRdTable' defined in .dtcm section in ArmLdmStmRd.o
(.dtcm+0x18): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmStmRnTable_1' defined in .dtcm section in ArmLdmStmRn.o
(.dtcm+0x1a): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armStmRdTable' defined in .dtcm section in ArmLdmStmRd.o
(.dtcm+0x20): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmStmRnTable_1' defined in .dtcm section in ArmLdmStmRn.o
(.dtcm+0x22): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmRdTable' defined in .dtcm section in ArmLdmStmRd.o
(.dtcm+0x28): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armLdmStmRnTable_0' defined in .dtcm section in ArmLdmStmRn.o
(.dtcm+0x2a): relocation truncated to fit: R_ARM_ABS16 against symbol `memu_armStmRdTable' defined in .dtcm section in ArmLdmStmRd.o
(.dtcm+0x30): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
This is on Ubuntu 22.04.3 LTS with latest devkitpro/devkitARM
arm-none-eabi-gcc (devkitARM release 62) 13.2.0
It doesn't make sense that it compiles on Windows but not Linux when it should be the same toolchain. Can anyone compiling with a MinGW setup share the GCC version it's using?
I tried building it locally on Mac as well as remotely, with GitHub Actions on Linux (Ubuntu 22.04). Both builds fail. Here's the full output of the GitHub Action:: https://github.com/wujekbogdan/GBARunner3/actions/runs/8037047694/job/21951456702
And I get this trying to build on Windows with a stock install. Haven't really investigated further.
The relocation errors I expect are probably a difference in link order caused by differences in globbing (i.e. objects declared in a different order when linking).
make[2]: Entering directory '/home/davem/projects/GBARunner3/code/test/arm9' main.cpp In file included from C:/Users/davem/projects/GBARunner3/code/libs/googletest/include/gtest/internal/gtest-port.h:442, from C:/Users/davem/projects/GBARunner3/code/libs/googletest/include/gtest/gtest-message.h:57, from C:/Users/davem/projects/GBARunner3/code/libs/googletest/include/gtest/gtest-assertion-result.h:46, from C:/Users/davem/projects/GBARunner3/code/libs/googletest/include/gtest/gtest.h:68, from C:/Users/davem/projects/GBARunner3/code/test/arm9/source/main.cpp:3: C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:45: error: expected primary-expression before '__restrict' 99 | size_t, regmatch_t [__restrict], int); | ^~~~~~~~~~ C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:45: error: expected ']' before '__restrict' 99 | size_t, regmatch_t [__restrict], int); | ^~~~~~~~~~ | ] C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:45: error: expected ')' before '__restrict' 99 | size_t, regmatch_t [__restrict], int); | ^~~~~~~~~~ | ) C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:98:16: note: to match this '(' 98 | int regexec(const regex_t *__restrict, const char *__restrict, | ^ C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:55: error: expected initializer before ']' token 99 | size_t, regmatch_t [__restrict], int); | ^ C:/Users/davem/projects/GBARunner3/code/test/arm9/source/main.cpp: In function 'void testMain(int, char**)': C:/Users/davem/projects/GBARunner3/code/test/arm9/source/main.cpp:39:18: warning: ignoring return value of 'int RUN_ALL_TESTS()' declared with attribute 'warn_unused_result' [-Wunused-result] 39 | RUN_ALL_TESTS(); | ~~~~~~~~~~~~~^~ make[3]: *** [/opt/devkitpro/devkitARM/base_rules:34: main.o] Error 1
The default target is the all
target:
all: checklibtwl checkbootstrap checktest
Compilation on Windows works fine. It's the checktest
target that fails - both preceding tasks complete successfully.
I compiled the code on Windows today disabling the checktest
task.
It seems that something might have changed in devkitarm that now causes Google Test to fail to compile. I'm using an out-if-the-box devkitarm version of a few months ago on my windows pc and everything works fine with it. Other people also have compiled the project, and only since a few weeks there were suddenly reports about this "regex" error, without anything having changed with regard to the test project.
I'm using an out-if-the-box devkitarm version
What are you referring to by "out-of-the-box" version? How can I obtain it?
On the official devkitPro site, they provide 2 ways of installing the tool on Windows - either via the devkitPro Updater GUI or via msys2
+ pacman
. Both result in the most recent version of devkitARM being installed.
I just mean a clean version that has not been tampered with. Devkitpro doesn't provide older versions, but there are some websites that host them.
And I get this trying to build on Windows with a stock install. Haven't really investigated further.
The relocation errors I expect are probably a difference in link order caused by differences in globbing (i.e. objects declared in a different order when linking).
make[2]: Entering directory '/home/davem/projects/GBARunner3/code/test/arm9' main.cpp In file included from C:/Users/davem/projects/GBARunner3/code/libs/googletest/include/gtest/internal/gtest-port.h:442, from C:/Users/davem/projects/GBARunner3/code/libs/googletest/include/gtest/gtest-message.h:57, from C:/Users/davem/projects/GBARunner3/code/libs/googletest/include/gtest/gtest-assertion-result.h:46, from C:/Users/davem/projects/GBARunner3/code/libs/googletest/include/gtest/gtest.h:68, from C:/Users/davem/projects/GBARunner3/code/test/arm9/source/main.cpp:3: C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:45: error: expected primary-expression before '__restrict' 99 | size_t, regmatch_t [__restrict], int); | ^~~~~~~~~~ C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:45: error: expected ']' before '__restrict' 99 | size_t, regmatch_t [__restrict], int); | ^~~~~~~~~~ | ] C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:45: error: expected ')' before '__restrict' 99 | size_t, regmatch_t [__restrict], int); | ^~~~~~~~~~ | ) C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:98:16: note: to match this '(' 98 | int regexec(const regex_t *__restrict, const char *__restrict, | ^ C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:55: error: expected initializer before ']' token 99 | size_t, regmatch_t [__restrict], int); | ^ C:/Users/davem/projects/GBARunner3/code/test/arm9/source/main.cpp: In function 'void testMain(int, char**)': C:/Users/davem/projects/GBARunner3/code/test/arm9/source/main.cpp:39:18: warning: ignoring return value of 'int RUN_ALL_TESTS()' declared with attribute 'warn_unused_result' [-Wunused-result] 39 | RUN_ALL_TESTS(); | ~~~~~~~~~~~~~^~ make[3]: *** [/opt/devkitpro/devkitARM/base_rules:34: main.o] Error 1
@WinterMute the issue has been tracked down to this commit in newlib, introduced in 4.4.0 https://github.com/devkitPro/newlib/commit/3c75fac130b5720068707f67b12f4372abf4ad38, in prior newlib versions, __restrict
in c++ mode ended up being declared as an empty macro, thus not causing any issue, but after that commit, newlib authors assumed __restrict
is always available if gcc is greater than 2.95, thus don't define their own macro, but this logic doesn't seem to hold with the gcc version that is shipped by dkp (even when building code as gnu++, which is the case of gbarunner3, the __restrict
keyword is unrecognized)
#include <sys/types.h>
#include <regex.h>
int main() {
return 0;
}
This is a very barebone example, compile this "program" with the arm9 template project, without changing anything at all other than renaming main.c
to main.cpp
to compile as c++, it'll error out the same way In file included from C:/devkitPro/examples/nds/templates/arm9/source/main.cpp:2: C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:45: error: expected primary-expression before '__restrict' 99 | size_t, regmatch_t [__restrict], int); | ^~~~~~~~~~ C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:45: error: expected ']' before '__restrict' 99 | size_t, regmatch_t [__restrict], int); | ^~~~~~~~~~ | ] C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:45: error: expected ')' before '__restrict' 99 | size_t, regmatch_t [__restrict], int); | ^~~~~~~~~~ | ) C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:98:16: note: to match this '(' 98 | int regexec(const regex_t *__restrict, const char *__restrict, | ^ C:/devkitPro/devkitARM/arm-none-eabi/include/regex.h:99:55: error: expected initializer before ']' token 99 | size_t, regmatch_t [__restrict], int);
(nb it still errors out even if compiled as gnu++23, or any other c++ standard). The same code compiled with the r62 toolchain with nelib 4.3.0 compiles as expected.
@edo9300 thanks for that. Could you do me a favour & pop that on our issue tracker @ https://github.com/devkitPro/newlib/issues will look when I get some time.
As of commit 18cda12c3b6c6f5d65f68e028adc41cbcee35301 GBARunner3.nds
now compiles on Linux.
test
still has issues which has been reported to devkitPro above.
I just compiled the latest source code earlier today after reading about some people having some problems. I was successful, after a bit of trial and error. I was able to figure out where to begin, easily, which was the twl library after something gave me an ld.exe compiler error about that missing library. after that, I compiled arms 7 and 9, then bootstrap. that was the order I went in. compiling with the main make file results in an error with bootstrap, but I think it makes test correctly. sound is now working, albeit, with some anomalies, depending on the game, but the games themselves seem to work very well from what I saw. anyway, this was just a fyi, since you asked me how I compiled it the first time with some people were having some trouble. I made a mental note of what I did this time, so I'll put the information here for others as well as myself, when I compile again.