simple64 doesn't boot on devuan.

[FrostKnight]

Describe the bug
I get this when I try to run simple64 via flatpak:
user@host:~$ flatpak run io.github.simple64.simple64
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

and then it refuses to run.

Expected behavior
simple64 should startup.

Screenshots
Add screenshots and/or a video to help explain your problem.
These really help when trying to find bugs, please include them!

Desktop (please complete the following information):

• OS: Devuan daedalus its based on debian bookworm
• GPU: Intel HD 4000]

Additional context
Nothing to speak of

I tried this because I wanted to try netplay.

[Jj0YzL5nvJ]

Upgrade from bullseye to bookworm? For things like that it's always preferable to install from scratch...

Try:

sudo apt-get update
sudo apt-get --reinstall install gtk3-nocsd
sudo dpkg-reconfigure -f gtk3-nocsd
sudo ldconfig

[FrostKnight]

the third command failed:

sudo: unable to resolve host host.localdomain: Name or service not known
debconf: unable to initialize frontend: Gtk3-nocsd
debconf: (Can't locate Debconf/FrontEnd/Gtk3.pm in @inc (you may need to install the Debconf::FrontEnd::Gtk3 module) (@inc contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at (eval 15) line 2.)
debconf: falling back to frontend: Noninteractive
/usr/sbin/dpkg-reconfigure: please specify a package to reconfigure
sudo: unable to resolve host localhost.localdomain: Name or service not known

Annoying thing is, I do have the gtk3 module installed of debconf... so weird.

Also, in case it worked without, I did that same command without the -f,

did not work.

[Jj0YzL5nvJ]

sudo: unable to resolve host localhost.localdomain: Name or service not known

https://old.reddit.com/r/debian/comments/paxg6v/after_update_sudounable_to_resolve_host/ha96xyx/

Examples:
$ cat /etc/hostname

computername

$ cat /etc/hosts

127.0.0.1	localhost
127.0.1.1	computername

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Check for localhost.localdomain alias on /etc/hosts... if not exist, try adding:

127.0.0.1	localhost localhost.localdomain

[FrostKnight]

Still no dice, I think it isn't related to the network, this problem. Although oddly enough, I had this problem with a different emulator of a similar kind from flatpak known as gopher64. I wonder if its a flatpak issue.

Its a pity I can't build this from source without flatpak and install it. Maybe then I could get it working.

That is definitely something I would appreciate, but if not, oh well.

Btw, how would I be able to check if its a flatpak issue and not an operating system issue?

[Jj0YzL5nvJ]

Still no dice, I think it isn't related to the network, this problem.

Many programs use sockets even without using "the network" itself. Personally, I have never seen the alias localhost.localdomain, but issues with such alias seem to be common on KDE desktop (according to Google).

I had this problem with a different emulator of a similar kind from flatpak known as gopher64.

How funny, both emulators share the same developer...

Btw, how would I be able to check if its a flatpak issue and not an operating system issue?

Trying to use a third or fourth app in Flatpak? To me, the symptoms reek of a missing configuration.

Try:

sudo apt-get update
sudo apt-get purge gtk3-nocsd
sudo apt-get --reinstall install libgtk3-nocsd0
sudo dpkg-reconfigure -f libgtk3-nocsd0
sudo ldconfig

[FrostKnight]

Still no dice, I think it isn't related to the network, this problem.

Many programs use sockets even without using "the network" itself. Personally, I have never seen the alias localhost.localdomain, but issues with such alias seem to be common on KDE desktop (according to Google).

I wasn't using a desktop environment though. I was using jwm.

I had this problem with a different emulator of a similar kind from flatpak known as gopher64.

How funny, both emulators share the same developer...

Interesting... I tried one other app as you suggested, apparently it had the same error, but it actually launched the program. Juk I believe was its name? its a media player

Btw, how would I be able to check if its a flatpak issue and not an operating system issue?

Trying to use a third or fourth app in Flatpak? To me, the symptoms reek of a missing configuration.

Try:

sudo apt-get update
sudo apt-get purge gtk3-nocsd
sudo apt-get --reinstall install libgtk3-nocsd0
sudo dpkg-reconfigure -f libgtk3-nocsd0
sudo ldconfig

I guess I can try again. the purge part I didnt do before.

[FrostKnight]

I did the first 4 steps again, same as above:

sudo dpkg-reconfigure -f libgtk3-nocsd0
debconf: unable to initialize frontend: Libgtk3-nocsd0
debconf: (Can't locate Debconf/FrontEnd/Libgtk3.pm in @inc (you may need to install the Debconf::FrontEnd::Libgtk3 module) (@inc contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at (eval 15) line 2.)
debconf: falling back to frontend: Noninteractive
/usr/sbin/dpkg-reconfigure: please specify a package to reconfigure

Not sure what this means...

[Jj0YzL5nvJ]

Try:

sudo apt-get update
sudo apt-get --reinstall install libgtk3-nocsd0 libgtk3-perl
sudo dpkg-reconfigure -f libgtk3-nocsd0
sudo ldconfig

Also try:

LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0" flatpak run io.github.simple64.simple64

Or:

sudo apt-get purge gtk3-nocsd libgtk3-nocsd0 libgtk3-perl
sudo ldconfig
sudo -k
sudo -K
unset LD_PRELOAD
flatpak run io.github.simple64.simple64

At this point I'm already out of ideas.

[FrostKnight]

Your last commands worked in getting rid of that ld error. Only weird thing is, simple64 still doesn't launch. I am curious whats going on myself.

Do you know if anyone has gotten this working on debian bookworm? Just wondered

[Jj0YzL5nvJ]

Unfortunately the requirements to run simple64 fluently are much higher than those of Project64 or mupen64plus. It's very likely that your CPU doesn't have the AVX2 instruction. See with: lscpu | grep 'avx'

See the simple64 FAQ for more prerequisites.

I recommend you RMG, the requirements are lower. The bad thing is that it doesn't have Netplay.

[FrostKnight]

Unfortunately the requirements to run simple64 fluently are much higher than those of Project64 or mupen64plus. It's very likely that your CPU doesn't have the AVX2 instruction. See with: lscpu | grep 'avx'

See the simple64 FAQ for more prerequisites.

I recommend you RMG, the requirements are lower. The bad thing is that it doesn't have Netplay.

There is the problem... lol. I want netplay

Its a pity retroarch doesn't have a netplay compatible version of a nintendo 64 emulator. :(

Why make the requirements so high anyways? Btw, yes I am using an ivy bridge quad core.

At least it isn't sandy bridge. (some people obsess over those because of being able to delete the intel me completely from the bios.)

I seek realistic expectations though. I avoid the network stack in that and the rest is well... meh. Coreboot + intel me neutered ftw.

But anywho, that's why... I have A t430 and an x230 both of which I guess can't run your stuff even with devuan. Pity, but oh well.

[Jj0YzL5nvJ]

There is the problem... lol. I want netplay

If you have a GOOD Android smartphone, you could alternatively try the pre-release version of Mupen64Plus-AE. The true publication date (update) is the file one. The one on the front is from the creation of the Pre-release tag.
Or M64Plus FZ by Francisco Zurita.

I don't know what the limitations and/or restrictions of Netplay are in each version. If they are the same as those of simple64, then you would be forced to always use the latest version published to date.

Why make the requirements so high anyways? Btw, yes I am using an ivy bridge quad core.

In layman's terms, is the developer's imposition. In reality it's a true necessity if you really want to have a good experience with simple64.
simple64 uses a fork of mupen64plus that removes A LOT of hacks that allow emulators based on mupen64plus to run on devices with very few resources. CountPerOp (count per operation or "counter factor"), Overclock, Dynarecs (both), etc.
Additionally, it adapts some of the improvements from other N64 emulators such as ares. Mainly those related to accuracy and timing.
With all that, the final product ends up being extremely taxing for the CPU in the synchronization area without SIMD extensions like AVX2 or higher.

I have personally rebuild the key components to be used as a plugins for UI Console with -march=amdfam10 (SSE2, SSE3, SSE4a). The experience is generally good on AMD Phenom II X6 1090T BE with the cached interpreter. But some games like CBFD require using the pure interpreter to function correctly, that is when the need for AVX2 becomes evident.
I don't rule out that it could work well with SSSE3, some other SSE4.x and AVX. But the CPU usage would ultimately be much higher for lower processor ranges without AVX2.

[FrostKnight]

That's a shame that's the result, although, I read on wikipedia, that Vulkan supposedly has the possibility of even supporting sandy bridge intel devices.

https://wikipedia.com/wiki/Vulkan?lang=en#2015

Ivy bridge is newer than that and yet it can't seem to work this. It does in fact have AVX support.

But if it ain't something that you plan to add, this probably is lockable. Appreciate the explanation though.

[Jj0YzL5nvJ]

By "key components" I was referring to the mupen64plus-core and parallel-rsp forks used by simple64. Certainly, parallel-rdp is a "key component" that Vulkan uses... but it barely uses CPU. However, it can easily bring upper mid-range GPUs to their knees depending on the settings... no wonder the x8 upscaling setting was removed (disabled).

In theory, Vulkan in software mode (CPU) could work with just the SSE2 instruction at 32 bits... but that would kill the whole purpose of using Vulkan in the first place (doing everything on the GPU).

From my point of view, the whole point/reason of forcing the use of AVX2 in simple64 is to guarantee good performance on low-end CPUs when using simple64's mupen64plus fork in pure interpreter mode. Or maybe it's just to lower the synchronization resources of the Netplay server... who knows.