Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arch Linux: LIB_MONO-NOTFOUND #22

Open
TheSandBoxMKG opened this issue Apr 30, 2020 · 9 comments
Open

Arch Linux: LIB_MONO-NOTFOUND #22

TheSandBoxMKG opened this issue Apr 30, 2020 · 9 comments

Comments

@TheSandBoxMKG
Copy link

Also, apt-get is used in the BundleMono.sh script, which is not an one-size-fits-all solution between distros that do not use the same package manager.

Terminal log (some contents are in Spanish since my system language is set to Spanish)
https://gist.github.com/TheSandBoxMKG/cae0d939bbb6914a687d95b254d7ee9d

@TheSandBoxMKG
Copy link
Author

TheSandBoxMKG commented May 8, 2020

I compiled the latest release of mono (mono-6.8.0.105.tar.xz) with the prefix set to a folder in the PCSX2 plugin directory and I tried hacking around some of the project files, whose changes can be seen here:
https://gist.github.com/TheSandBoxMKG/84e4edb0b8f680d49fbab52ec43f778b
Notice that I had to remove the usr in some parts and that is because I forgot to add the usr in the prefix when compiling Mono.

So far it builds, but for some reason it crashes when I go to the plug-in selection menu. Strace log using LC_ALL=C strace PCSX2 2>pcsx2strace.txt here:
pcsx2strace.txt

Looks like that even with a custom prefix set, somehow my version of Mono (or the plug-in) are still searching some components in the 64-bit libraries and therefore crash as they clash.

EDIT: Additional notes about the mono build, it went something like this:

export PREFIX=/usr/lib32/pcsx2/mono_i386
export VERSION=6.8.0.105
tar xvf mono-$VERSION.tar.xz
cd mono-$VERSION
./configure --prefix=$PREFIX --build=i386-pc-linux-gnu "CFLAGS=-m32" "CXXFLAGS=-m32" "LDFLAGS=-m32"
make
sudo mkdir /usr/lib32/pcsx2/mono_i386
sudo chmod 755 /usr/lib32/pcsx2/mono_i386
sudo chown genstar:genstar /usr/lib32/pcsx2/mono_i386
make install

and then copied the mono_i386 from /usr/lib32/pcsx2 to the CLR_DEV9_LINUX_MONO directory in the project after commenting out the BundleMono.sh command in the build.sh file.

EDIT 2: Also, I'm getting the source code of this plug-in by git-cloning this repository. Is the repository outdated?

EDIT 3: Added something I forgot to note

@TheSandBoxMKG
Copy link
Author

Okay, I've looked in the strace and it looked like it was searching for mono in /usr/lib32/pcsx2/mono_i386/usr instead of /usr/lib32/pcsx2/mono_i386. So I've just decided to recompile mono again with the prefix changed to /usr/lib32/pcsx2/mono_i386/usr and then rebuilt this project from scratch but this time I did not change CMakeLists.txt, just build.sh so it does not call BundleMono.sh (Also, copied the mono_i836 folder manually as always)

Now it goes futher, letting me select the plug-in and applying the plug-in selection but it crashes either when trying to configure the plug-in via the UI or when booting up the emulation with the plug-in loaded without configuring it.

Attachments are strace outputs.

@TheSandBoxMKG
Copy link
Author

TheSandBoxMKG commented May 8, 2020

Advancements:
Compiled the 32 bit version of libgdiplus in the same prefix as Mono and now the plug-in configuration opens (albeit with an ugly Windows 9x like dialog). Didn't recompile CLRDEV9.

Emulation still crashes when starting but at least it doesn't grind PCSX2 to a halt (instead, it says that the plug-in had a problem and stops emulation)

EDIT: I've compiled CLR-DEV9 again. Still no success.
By the way, this is what the dialog shows before stopping emulation:

Object reference not set to an instance of an object
  at CLRDEV9.Utils.memcmp (System.Byte[] target, System.Int32 targetstartindex, System.Byte[] source, System.Int32 sourcestartindex, System.Int32 num) [0x00008] in <389612a8ed7b49dc9cd82d6dade10de5>:0 
  at CLRDEV9.DEV9.SMAP.Winsock.Sessions.UDP_DHCPSession.HandleDNS (System.Net.NetworkInformation.NetworkInterface parAdapter, System.Byte[] parDNS1, System.Byte[] parDNS2) [0x00166] in <389612a8ed7b49dc9cd82d6dade10de5>:0 
  at CLRDEV9.DEV9.SMAP.Winsock.Sessions.UDP_DHCPSession..ctor (CLRDEV9.DEV9.SMAP.Winsock.ConnectionKey parKey, System.Net.NetworkInformation.NetworkInterface parAdapter, System.Byte[] parDNS1, System.Byte[] parDNS2, System.Boolean parLANMode) [0x000ff] in <389612a8ed7b49dc9cd82d6dade10de5>:0 
  at CLRDEV9.DEV9.SMAP.Winsock.Winsock..ctor (CLRDEV9.DEV9.DEV9_State parDev9, System.String parDevice) [0x001f0] in <389612a8ed7b49dc9cd82d6dade10de5>:0 
  at CLRDEV9.DEV9.SMAP.AdapterLoader.GetNetAdapter () [0x00035] in <389612a8ed7b49dc9cd82d6dade10de5>:0 
  at CLRDEV9.DEV9.SMAP.AdapterLoader.Open () [0x00001] in <389612a8ed7b49dc9cd82d6dade10de5>:0 
  at CLRDEV9.DEV9.SMAP.SMAP_State.Open () [0x00001] in <389612a8ed7b49dc9cd82d6dade10de5>:0 
  at CLRDEV9.DEV9.DEV9_State.Open (System.String hddPath) [0x0002e] in <389612a8ed7b49dc9cd82d6dade10de5>:0 
  at CLRDEV9.CLR_DEV9.Open (System.IntPtr winHandle) [0x00064] in <389612a8ed7b49dc9cd82d6dade10de5>:0 

EDIT2: another report: enabling HDD with an image created from the plug-in does not crash the emulation. I haven't been able to test further as I don't know much about using HDDs on PlayStation 2 (The HDD does not show in the BIOS but I'm guessing that's expected).

@TheLastRar
Copy link
Owner

Sorry for the delayed response

Yes I'm aware that the apt based BundleMono script is not portable across every distribution, but I never gotten around to resolving that

The repo is up-to-date, I've just not worked on it in a while.

While the UI looks okay on windows, it looks bad on linux, It's an issue with mono's implementation of winforms.

Regarding HDD support, you would need to format the virtual HDD using the PS2 HDD utility disk
A small number games support HDD, as well as using the HDD to store games with the use of homebrew such as HDLoader.

Are your CLR_DEV9 Ethernet settings the default?

@TheSandBoxMKG
Copy link
Author

Yes, the CLR_DEV9 Ethernet settings are set to the default ones.
image
From the list of connections methods, only Winsock is available.
The Options button:
image

@TheLastRar
Copy link
Owner

Can you try changing the adapter from Auto to your actual adapter

It's possible that Auto is failing to select the correct adapter in some systems

@TheSandBoxMKG
Copy link
Author

Can you try changing the adapter from Auto to your actual adapter

It's possible that Auto is failing to select the correct adapter in some systems

Does it need to be an Ethernet adapter or a wireless one is fine? because I've already tried setting this to the wireless adapter and same result
image

@TheLastRar
Copy link
Owner

I've pushed a commit, can you try rebuilding from that

@TheSandBoxMKG
Copy link
Author

Rebuilt from latest commit and now the plug-in does not crash at boot when Ethernet is enable. Further testing needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants