RetroArch [ERROR] :: rarch_main_init :: Fatal error received in: "load_dynamic()"

[andres-asm]

From @joolswills on June 27, 2015 19:12

running version 8b963ce24ff3ee32f5dbd6157ed0582203a71a66

building with make -f Makefile.libretro platform=armvhardfloat

rarch_main_init: === Build =======================================RetroArch: rarch_get_cpu_features: [CPUID]: Features:
Built: Jun 24 2015
rarch_main_init: Version: 1.2
rarch_main_init: Git: a7d3975
rarch_main_init: =================================================
RetroArch: rarch_get_cpu_features: [CPUID]: Features:
RetroArch: parse_config_file: Loading config from: /opt/retropie/configs/all/retroarch.cfg.
RetroArch: load_symbols: Loading dynamic libretro from: "/opt/retropie/libretrocores/lr-mgba/mgba_libretro.so"
RetroArch [ERROR] :: load_symbols :: Failed to open dynamic library: "/opt/retropie/libretrocores/lr-mgba/mgba_libretro.so"
RetroArch [ERROR] :: rarch_main_init :: Fatal error received in: "load_dynamic()"

revision e16338f4170c49bcfe7a1d5861c9426960f4fd8f works

had trouble git bisecting as it seems that for many revisions in between e16338f4170c49bcfe7a1d5861c9426960f4fd8f and 8b963ce24ff3ee32f5dbd6157ed0582203a71a66 the Makefile.libretro is missing (is this caused by a forced push or rebase or something ?)

Copied from original issue: libretro/mgba#5

[andres-asm]

From @joolswills on June 27, 2015 19:16

eg. Where is Makefile.libretro in this commit

https://github.com/libretro/mgba/commit/a85ae6563c1008685ccd91fcedc1bb2846139ad6

https://github.com/libretro/mgba/tree/a85ae6563c1008685ccd91fcedc1bb2846139ad6

[andres-asm]

it's not there of course, there is no Makefile.libretro in mgba upstream

[andres-asm]

From @joolswills on June 27, 2015 19:34

that commit is from libretro though no ? - I realise it's merged from upstream ? I guess you are managing this differently - How can I debug where this breaks then if I can't use git bisect ?

[andres-asm]

From @joolswills on June 27, 2015 19:37

I guess it's because you are using rebase rather than merging from upstream ?. Anyway, any help to debug this is appreciated thanks.

[andres-asm]

Actually I'm not rebasing, I'm merging, upstream doesn't want the makefile in their tree, so I merge, fix the makefile and move forward. I guess you could copy the makefile to the commits

[andres-asm]

From @joolswills on June 27, 2015 19:39

ill try that.

[andres-asm]

From @joolswills on June 27, 2015 20:10

Bisecting and copying Makefiles to each commit - it breaks as of

47d945bf75c4a43307698393a57b015d7373e716

[andres-asm]

From @joolswills on June 27, 2015 21:18

Not sure how this bug wasn't picked up before, as I can't see how this will work on any platform currently. I have now got the latest code to work by doing

cmake . - just to create version.c

and then

diff --git a/Makefile.common b/Makefile.common
index 1168c54..23ff393 100644
--- a/Makefile.common
+++ b/Makefile.common
@@ -49,7 +49,8 @@ SOURCES_C :=   $(CORE_DIR)/arm/arm.c \
                                        $(CORE_DIR)/util/string.c \
                                        $(CORE_DIR)/util/hash.c \
                                        $(CORE_DIR)/util/configuration.c \
-                                       $(CORE_DIR)/util/crc32.c
+                                       $(CORE_DIR)/util/crc32.c \
+                                       version.c

 SOURCES_C += $(CORE_DIR)/util/circle-buffer.c
 #SOURCES_C += $(CORE_DIR)/debugger/gdb-stub.c

and all loads fine (the symbols can be found).

the libretro makefile needs to be updated to generate version.c I guess (or it needs documenting that you still need to use cmake to generate the version.c even if building for libretro), and then the version.c needs compiling/linking with the patch above.

[andres-asm]

it works on other platforms because I'm currently defining what version.c defines manually during builds, it was a hack I came out with the other night

[andres-asm]

From @joolswills on June 27, 2015 21:21

an even easier fix

diff --git a/Makefile.common b/Makefile.common
index 1168c54..ba252f5 100644
--- a/Makefile.common
+++ b/Makefile.common
@@ -27,7 +27,6 @@ SOURCES_C :=   $(CORE_DIR)/arm/arm.c \
                                        $(CORE_DIR)/gba/sio/lockstep.c \
                                        $(CORE_DIR)/gba/video.c \
                                        $(CORE_DIR)/gba/serialize.c \
-                                       $(CORE_DIR)/gba/supervisor/config.c \
                                        $(CORE_DIR)/gba/supervisor/rr.c \
                                        $(CORE_DIR)/gba/supervisor/cli.c \
                                        $(CORE_DIR)/gba/supervisor/overrides.c \

[andres-asm]

From @joolswills on June 27, 2015 21:21

(config.c doesn't seem to be needed - and then those symbols are not needed either)

[andres-asm]

I don't know I can't follow stuff like this... it's building fine right now on windows/linux at least, if you have a solution send a PR, that's better.

I just built the latest trunk just fine, but yeah the hacks I implemented for it to build were windows only.

[andres-asm]

From @joolswills on June 27, 2015 21:28

I can send a pull request to remove config.c - I was running the fixes by you so you could tell me which you preferred (or come up with a better fix). If you have no preference, ill just remove the config.c and send a PR.

It may be building fine, but if there are symbols being used that are not resolved, the library won't load.

[andres-asm]

it doesn't build without config.c in windows and my personal builds are working fine there

[andres-asm]

The reason upstream commits require version.c is because libretro.c is different between our fork and upstream, I removed the references of projectVersion and projectName there

[andres-asm]

From @joolswills on June 27, 2015 21:30

maybe the shared library loader is less fussy if symbols are missing. it's still a bug though. what error do you get if config.c is missing on windows ?

[andres-asm]

see my latest comment

[andres-asm]

From @joolswills on June 27, 2015 21:40

Yep, but there is one left - which I guess was missed as it's non windows only.

I propose this fix then - i'll PR if you agree.

diff --git a/src/gba/supervisor/config.c b/src/gba/supervisor/config.c
index 3734424..35913c1 100644
--- a/src/gba/supervisor/config.c
+++ b/src/gba/supervisor/config.c
@@ -130,7 +130,7 @@ void GBAConfigDirectory(char* out, size_t outLength) {
        char* home = getenv("HOME");
        snprintf(out, outLength, "%s/.config", home);
        mkdir(out, 0755);
-       snprintf(out, outLength, "%s/.config/%s", home, binaryName);
+       snprintf(out, outLength, "%s/.config/%s", home, PROJECT_NAME);
        mkdir(out, 0755);
 #else
        char home[MAX_PATH];
diff --git a/src/util/common.h b/src/util/common.h
index bdf5af4..eec0863 100644
--- a/src/util/common.h
+++ b/src/util/common.h
@@ -19,8 +19,6 @@
 #include <stdlib.h>
 #include <string.h>

-#include "version.h"
-
 #ifdef _MSC_VER
 typedef intptr_t off_t;
 typedef intptr_t ssize_t;

removing version.h will help so we get errors when building rather than when loading the libretro module.

[andres-asm]

if it works send the PR

[andres-asm]

From @joolswills on June 27, 2015 21:48

6