Failed to load Core on Windows

[Zewwy]

When I try to load a game in Ludo, it asks me to load a core first,

this kind of sucks compared to the logic of Lakka, which asks to pick from a list of cores after selecting a game to load.

So ok, go to cores, pick any core from the list, and you'll simply be greeted with failed to load core.

[RobLoach]

Posted my logs of this happening on Windows over at: #89 (comment)

ludo -L "C:\Users\rob_l\Desktop\Ludo\cores\nestopia_libretro.dll" "10-Yard Fight (Japan).zip"
panic: Failed to load C:\Users\rob_l\Desktop\Ludo\cores\nestopia_libretro.dll: The specified module could not be found.        
goroutine 1 [running, locked to thread]:
main.main() 

C:/Users/travis/gopath/src/github.com/libretro/ludo/main.go:101 +0x604                

This affects Windows, but not Linux.

[Zewwy]

correct, all verisons of Windows.

[kivutar]

I've tested the latest release, and can't reproduce this bug. I'm on Windows 10 64bit.
I was able to launch Super Bomberman 5 on snes9x.

I would need more information about your Windows.

[Zewwy]

Not sure what details you want, regardless if I try ludo on Windows 7 or Windows 10. It simply fails to load the cores. Let me get you some snippets....

Windows 7 Laptop

https://i.imgur.com/sthxW5r.png

Windows 10 gaming Desktop

https://i.imgur.com/7GeZpD7.png

[Zewwy]

It maybe a dependency thing, can you enlighten me on how to get this GLFW dependency?

all your instruction state is

"On Windows
Setup openal headers and dll in mingw-w64 include and lib folders."

I've been a windows admin for a long time and these instructions mean literally nothing to me. I managed to get the compiled Windows x64 binaries, but they are simply dll's and do not have a installation package. So I have no idea where I should put these?

[kivutar]

It maybe a dependency thing, can you enlighten me on how to get this GLFW dependency?

No, the loading of a DLL has nothing to do with GLFW which is a graphic library.

And GLFW doesn't need installation for Ludo, as it is statically linked in it.

It must be something else, something trickier. See https://blog.pcrisk.com/windows/12626-how-to-fix-qthe-specified-module-could-not-be-foundq-error

"Setup openal headers and dll in mingw-w64 include and lib folders"
I've been a windows admin for a long time and these instructions mean literally nothing to me.

Let me give you more detailed instructions: https://github.com/libretro/ludo/blob/master/.travis.yml#L72-L79

Can you tell me the versions of Ludo and Windows you're using? Including processor architecture (32bit or 64bit), please.

[Zewwy]

Those details are in both images I shared above :D

AFAIK it can't run on 32bit, so both are 64 bit. Running only the latest build of Ludo 0.2.7.

Checking your references now. Thanks for the help.

[Zewwy]

Sorry man, I don't think all our versions of windows are at fault here. I'm sure most people will not use this app with windows as it probably won't work for most people.

[Zewwy]

Just for quick sakes test on My Windows 10 1709 x64 workstation at work, since I'm literally running out of windows machines to try and guess what... also literally grabbed the latest compiled build too 0.2.8

Same error...

I know at one point in the cmd windows I do remember seeing c:\something\user./something/somefile

Like the linux/windows syntax got mixed, but I can't for the life of me see it anywhere anymore

[kivutar]

OK thanks for this precious informations. I'll make this a top priority issue, as I want to support Windows.
But I need to find a way to reproduce this bug on my machine.

[kivutar]

I've created a branch with an automated test for core launching.

The test is passing on my local windows, invoked from Bash and from Cmd:

We'll see if I can make it pass on Travis.

[kivutar]

OK I'm now able to reproduce on Travis.

This exit status 3221225781 that we see during go test is related to a DLL issue, according to hybridgroup/gocv#38

The solution will certainly be related to the CGO flags.
The fact that the tests are failing in audio, core, and input suggest that the issue is related to OpenAL.

[Zewwy]

Thanks for all your hard work on this!

[kivutar]

No problem. I'm a little bit stuck on this one however, can somebody try to setup the official OpenAL and OpenAL SDK from https://www.openal.org/ and see if it fixes it with either the Ludo release or a freshly compiled Ludo?

[Zewwy]

I can try what you ask with some guidance.

What do you mean by "setup the official OpenAL and OpenAL SDK"?

Just install the compiled binaries? Then try to run Ludo?

Well Installed both Core and the SDK, then attempted to load a core in Ludo. Same Error.

Not sure if you wanted me to move a dll, register a different dll (using regsrv32) or something?

[kivutar]

OK thanks for the test. You did what I meant.

[Zewwy]

Oh that Win---Dohs!!!

[kivutar]

I've tested one thing: removing OpenAL from the branch. And the issue is still there. Which means that the problem happens when loading the libretro core DLL or OpenGL. Not OpenAL.

[Zewwy]

mhm strange... what could be special about your windows to make the loading work... But fail on all my Windows machines and Robs...

I'm mostly familiar with special software logs (Like SharePoint's UNLS, or Exchange logs, and Windows Event Viewer) but not so much dedicated open source programs. Any ideas on how I could provide you some sort of logs? maybe a special compiled build with logging enable to a file?

[kivutar]

I honestly don't know.

If it was OpenAL, I could think that it was due to the fact that I have a few SDK installed on my windows.

But currently I don't know which DLL fails to load. We need to find a way to know that.

[kivutar]

See also golang-ui/nuklear#12

[Zewwy]

well I'm not sure what any of that means, but I did what I could to help,

So I ran proc mon, Here's running Ludo after clearing out all the "noise"

to see what was happening when I attempted to load a core...

What's this system hard on to find winlibpthread-1.dll?

[Zewwy]

Best I could find about this dll is its linked to minGW64? Source

Also maybe this thread is of help?

HaxeFoundation/hxcpp#339

[kivutar]

Looks like we need to add mingw to the path https://stackoverflow.com/questions/28907304/cc1-exe-system-error-libwinpthread-1-dll-missing-but-it-isnt

[kivutar]

OpenBazaar fixed it this way: https://github.com/OpenBazaar/openbazaar-go/pull/319/files

[kivutar]

I've published a new release that includes this DLL. Can you try again with this please?
I was able to run it and load a core using wine.
It's still failing in Travis however. So I'm not sure if the fix is enough.

[Zewwy]

I'll grab the latest build and run another test. Thanks again. :)

Wooooo! You may want to ask Rob if he'd like to test this latest build cause I was finally able to load a game...

OK now that is finally out of the way...

1. How do you rebind keys like in Lakka?

right now the hardest part is figuring out controls, It would be nice to be allowed to rebind other keys to navigate the menu, and in game keys.

2. The navigation system needs work.

I noticed I was stuck in my C:\ when "loading a game", so at first I was wondering where the hecks my ROMs folder was, which was on another drive. No matter how much you click the top "..." it won't go all the way back to select a drive.

3. The menu system on my gaming machine is tooo responsive, when I press one key it'll move the menu 2-3 places, however when I was navigating the menu on my slower laptops it seemed fine.

4. I don't like having to manually load a core before a game, Lakka asks you what core you like to load when you select a rom file without loading a specific core. I like this, also I suppose building playlists. I haven't got into Ludos documentation on building playlists but I hope it doesn't do the mix weirdness of lakka were it wastes so many lines being 6 lines for one playlist item. instead of something simpler like a CSV.

Not sure if you want to make separate issues for all these or not. But I'd love to keep beta testing and providing feedback.

I'll test on a couple more machines, but I believe that was it. High Five!

[kivutar]

OK it's cool that this bug is finally fixed.
We can discuss your 4 points on Discord, as this thread is only about the DLL issue.
And the issue tracker is not the right place to have conversations and brainstorms.