Gericom / GBARunner3

205 stars 28 forks source link

FYI, How to Compile #57

Open godreborn opened 10 months ago

godreborn commented 10 months ago

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.

godreborn commented 10 months ago

I got the main make file to work, but you can't use it at first:

image

Gericom commented 10 months ago

It sounds like you didn't clone with submodules

godreborn commented 10 months ago

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: image

imo, this tends to suggest that when it builds that arm file, it's sometime after when it's needed to build bootstrap.nds.

Gericom commented 10 months ago

Normally you'd run the root makefile without using -j or so and it should build everything

godreborn commented 10 months ago

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?

Gericom commented 10 months ago

I think some dependencies are not setup correctly or so. When you run single threaded it'll run in the right order.

godreborn commented 10 months ago

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

Gericom commented 10 months ago

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

godreborn commented 10 months ago

good luck with that, my friend. I'd be more than happy to test compiling once it's done.

exelotl commented 10 months ago

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.
godreborn commented 10 months ago

I think I read there are issues with linux not compiling.

godreborn commented 10 months ago

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.

godreborn commented 10 months ago

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.

AkikoKumagara commented 10 months ago

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.

godreborn commented 10 months ago

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.

Dartz150 commented 10 months ago

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

beta215 commented 10 months ago

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

godreborn commented 10 months ago

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.

JORGETECH commented 10 months ago

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?

wujekbogdan commented 6 months ago

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

WinterMute commented 6 months ago

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

wujekbogdan commented 6 months ago

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.

Gericom commented 6 months ago

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.

wujekbogdan commented 6 months ago

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.

Gericom commented 6 months ago

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.

edo9300 commented 6 months ago

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)

edo9300 commented 6 months ago
#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.

WinterMute commented 6 months ago

@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.

lifehackerhansol commented 5 months ago

As of commit 18cda12c3b6c6f5d65f68e028adc41cbcee35301 GBARunner3.nds now compiles on Linux.

test still has issues which has been reported to devkitPro above.