lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores)

RealNC

@muldjord said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

Small update: I've been fiddling with the lr-dosbox-core core today (as mentioned by @mitu). It has some compilation issues which seem to stem from a problem in their repository. It's related to some of the fluidsynth stuff included. But I did manage to get it to compile eventually. Can't get it to run though... So from a pure ease-of-install perspective lr-dosbox-core is subpar. It doesn't even have built instructions or dependencies listed (it requires libsndfile1-dev) in the repository.

I've added some more information about dependencies:

https://github.com/realnc/dosbox-core

Most deps can now be bundled. They can be built together with the core and linked against statically. glib and alsa-lib are not, but I think these are available (and even installed by default) on virtually every Linux system.

muldjord

@RealNC Thank you for the update. I seem to be able to compile it now, but had some weird issues with configuring the fluidsynth lib. Anyways, I'll update you all on this when I have tested it.

RealNC

Sorry for the silly question, but I'm not familiar at all with retropie (or the rpi in general.) Don't the libretro buildbot ARM builds of dosbox-svn run as-is on retropi? I mean these:

http://buildbot.libretro.com/nightly/linux/

mitu

@RealNC They do work (I know I tested the armv7-neon-hf build for dosbox-svn). If the regular dosbox-libretro repository is no longer updated, I guess we can switch to dosbox-svn instead ?

I think the new dosbox-core is the one that's not working - due to the C++17 requirements. It builds, but I think I got a runtime error when loading the core. I can repeat the test to get the actual error.

RealNC

@mitu
In that case, I will look into adding ARM builds for dosbox-core. Right now it's only being built for Linux x86-64.

If you build yourself, then you need to pass STATIC_LIBCXX=1 to make so that libstdc++ and libgcc_s are statically linked. This is already being done for the x86 buildbot builds so that the core runs on old Linux distros as well.

mitu

@RealNC I'll give it a try.

RealNC

I was able to set up a build using Ubuntu 16.04 ARM 32-bit ("armhf"). I have no idea if it runs though, so it would be helpful if anyone could test:

https://github.com/realnc/dosbox-core/releases/download/latest_build/linux-armhf.zip

Munt, fluidsynth and bassmidi are all supported and built-in (except for bassmidi due to licensing) along with their dependencies (like vorbis, libsndfile, etc.) The only external library dependencies are:

libasound.so.2
libpthread.so.0
libgobject-2.0.so.0
libglib-2.0.so.0
libm.so.6
libc.so.6
ld-linux-armhf.so.3

which I believe should be already pre-installed on virtually all Linux systems out there.

mitu

@RealNC said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

https://github.com/realnc/dosbox-core/releases/download/latest_build/linux-armhf.zip

Seems to be ok on a PI4 (Raspbian Buster) system, I don't get any errors when starting.

I get a crash though trying to load a simple .conf file, but since the .so doesn't have debugging symbols, kind of difficult to say where it crashes. Could be because I don't have any soundfonts or some assets are missing.

EDIT: Compiling directly on a Raspbian Buster works, but even with STATIC_LIBCXX=1, there's still a runtime error about missing a new C++17 filesystems function. I think that's ok, Buster has only gcc 8.3.0, so it's missing the necessary requirements. Probably if compiled with a newer gcc/clang would work.

RealNC

@mitu said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

Seems to be ok on a PI4 (Raspbian Buster) system, I don't get any errors when starting.

I get a crash though trying to load a simple .conf file, but since the .so doesn't have debugging symbols, kind of difficult to say where it crashes. Could be because I don't have any soundfonts or some assets are missing.

It doesn't rely on any assets or soundfonts. I'll put up a debug build as well.

EDIT: Compiling directly on a Raspbian Buster works, but even with STATIC_LIBCXX=1, there's still a runtime error about missing a new C++17 filesystems function. I think that's ok, Buster has only gcc 8.3.0, so it's missing the necessary requirements. Probably if compiled with a newer gcc/clang would work.

Ah, with GCC 8 you need to add -lstdc++fs to LDFLAGS. The handling of that is wonky though. You probably have to edit Makefile.libretro and add in line 366, at the end of the line that starts with LDFLAGS += `$(PKGCONFIG)

RealNC

I uploaded a debug build as well:

https://github.com/realnc/dosbox-core/releases/download/latest_build/linux-armhf-dbg.zip

mitu

@RealNC I think it might be targeting the wrong (ARM) dynrec.

RealNC

@mitu said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

I think it might be targeting the wrong (ARM) dynrec.

It's the correct one for ARMv7. Does 32-bit stand-alone dosbox run fine when dynrec is enabled? (core = dynamic in the .conf file.) I think the rpi4 CPU is supposed to be backwards compatible with 32-bit ARMv7. So if stand-alone 32-bit dosbox with the same dynrec has the same issue, then this could be a bug in the dosbox dynrec.

I'll also put a 64-bit ARMv8 build up to see how that one behaves.

RealNC

Btw, if you disable the dynrec by setting the core's "System: CPU core" option to "normal", does it work then?

mitu

@RealNC Yes, the RPI4 (at least on Raspbian) should fall into the 32 bit ARMv7 category. Sadly 64 bit (ARMv8) would not work out-of-the-box since Raspbian has no 64 bit userspace support.

I tried the recommended settings (core and .conf) and it's still crashing - while the normal dosbox (upstream SVN) or dosbox-staging work fine.

RetroPie uses these build instructions when packaging upstream dosbox.

My testing .conf has just an autoexec section for starting Q1:

[autoexec]
mount c: /home/pi/roms/pc-data
c:
cd \quake1
quake -nocdaudio
exit

I think I'll try again to build the core - modifying the Makefile - and see if I can get it running locally, it might be an issue with the automated build.

RealNC

@mitu said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

I tried the recommended settings (core and .conf) and it's still crashing

Can you get a backtrace in this case? The old crash pointed to the dynrec, so with it disabled it should point somewhere else.

mitu

@RealNC Re-tested with core = dynamic and the crash is similar. Using the "System: CPU core" option to "normal" doesn't crash, but it's obviously slow.

RealNC

It's very difficult to debug this on my end, as I don't have any ARM devices. To check if this an issue with the toolchain, I built the regular dosbox-svn core with it:

http://83.212.109.87/~realnc/tmp/dosbox_svn_libretro.zip

Does it also crash?

mitu

@RealNC said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

Does it also crash?

No, it doesn't crash. I don't think the toolchain is at fault. Since the last update I managed to compile it natively (modifying the LDFLAGS) and I get a crash also.

I don't know if the core you linked (svn) is synchronized to the latest Dosbox SVN tag (I think dosbox-core is), but I'll install from source the latest Dosbox and see if maybe there's a recent regression.

RealNC

@mitu said in lr-dosbox-svn / lr-dosbox-core (new dosbox libretro cores):

I don't know if the core you linked (svn) is synchronized to the latest Dosbox SVN tag

No, it is kept in sync with SVN trunk. So that's not it.

I found something that might be the cause of it. I'll upload a new test build shortly.

RealNC

If you want to test locally if this is indeed the issue, edit Makefile.libretro and change this line near the beginning of the file:

CXXFLAGS += -std=c++17 -Dregister=

to:

CXXFLAGS += -std=c++17

Then do:

make <your other options here> targetclean`

and build again.

(targetclean only cleans core files, not deps, so that you don't have to rebuild deps again.)