Compile from Linux for Linux?

[TheLastRar]

You should be able to build the main plugin on linux using monodevelop (normal build), or vscode (.Net core build only), you may have issues with dllexport not being able to run its postbuild commands, you can ignore that if you only plan to use the build on Linux.

however, unlike windows a wrapper/loader is needed to load the plugin under Linux. Building this is a bit more complicated, MS build is setup to connect to a remote linux machine via SSH and build the project using G++ along with a command to auto install the plugin where PCSX2 installed on my linux machine

I'm was having difficulty getting a wrapper to work as well as well as the plugin does on windows, attempting to use both CoreCLR or Mono to perform the task.

The current state of the two different wrappers are as follows; A CoreCLR based wrapper (for the Core build of the plugin)

• Requires the x86 version CoreCLR, which you currently have to build yourself, the wrapper is hardcoded to look for this in /home/air/git/ReadyBin.Debug
• Currently requires the CLR_DEV9.dll plugin file to be saved in config directory.
• Might crash or have issues if you reload the plugin somehow
• Might hang PCSX2 on exit, see https://github.com/dotnet/corefx/issues/27935

A Mono based (for the normal build of the plugin, may work with the Core build)

• Requires the x86 version Mono, this is an issue as there is no multiarch support for mono
• msbuild embeds the plugin into the wrapper with the command objcopy --input binary --output elf32-i386 --binary-architecture i386 CLR_DEV9.dll $(RemoteProjectDir)/obj/CLR_DEV9.o resulting in a single file
• Mono can hang when unloading the plugin, I could not determine a fix for this at the time I encountered this issue.

[Fothsid]

Wow. Thanks for the reply. I can compile C++ part myself, but with which libraries I should link?

[TheLastRar]

CoreCLR based wrapper (CLR_DEV9_LINUX)

• lm, lrt, ldl, lpthread

Mono based (CLR_DEV9_LINUX_MONO)

• lmono-2.0, lm, lrt, ldl, lpthread
• You will also need to include the object file "CLR_DEV9.o" created using objcopy on CLR_DEV9.dll with the command in my previous comment

[Fothsid]

Can't compile main plugin... https://pastebin.com/L611WLRD

[TheLastRar]

In MonoDevelop (assuming that is what you are using), right click on the PSE folder and add the file "CLR_PSE_DummyExport.cs"

[Fothsid]

Compiled with mono, but seems like something gone wrong

[wx] /usr/lib32/pcsx2/libclrdev9.so: undefined symbol: mono_domain_set_config Path: /usr/lib32/pcsx2/libclrdev9.so File is not a valid dynamic library. Some kinda plugin failure: /usr/lib32/pcsx2/libclrdev9.so

[Fothsid]

nevermind, i just compiled with the old version of mono. anyways, now when I trying to open plugin selection window, pcsx2 crashes

[TheLastRar]

I forgot to mention that you need to include the mono headers located in /usr/include/mono-2.0 That is probably the cause of the error.

[Fothsid]

I included exactly these headers. I have runtime error.

[Fothsid]

Well, now it's not crashing, but just displays empty PCSX2 plugin selection window and it just hangs.

[TheLastRar]

What arguments are you using to build?, I can compare with what msbuild uses and see if there is something amis.

[Fothsid]

I created a simple CMakeLists.txt file, and builded everything using "cmake .. && make" CMakeLists.txt

[Fothsid]

Maybe it's because I manually installed 32 bit version of mono in /usr/lib32/ ...

[Fothsid]

I'm compiling CoreCLR for x86 right now, will try CoreCLR method.

[TheLastRar]

what method did you use to manually installed the 32 bit version of mono?

[Fothsid]

1. '-m32' flag in linker and compiler
2. because of this flag, linker automatically pickups required libraries from /usr/lib32, instead of /usr/lib. (at least on my system) (and also compiles everything for x86 arch)
3. I copied libmono-2.0 binary from the debian package of the testing branch(i386 arch) to /usr/lib32
4. that's all.

[TheLastRar]

Did you also copy the libmonosgen-2.0 binaries? those are required by libmono-2.0

[Fothsid]

Yes, I copied all dependencies, including libmonosgen-2.0

[TheLastRar]

Apologies, I had misread one of your comments and thought you where still having the undefined symbol.

Building with the CMake file produces a working build on my x86 VM, It probably is having issues with the manual install of mono for some reason.

edit: as an aside, you can use pass -rpath when linking to specify where to look for libraries at runtime, this is searched before usr/lib or usr/lib32

[TheLastRar]

Also, does anything get printed into the emulog file when PCSX2 crashes?

[Fothsid]

No, it just hangs until I kill process.

[TheLastRar]

Not even "Init Mono Runtime"?

[Fothsid]

Yes. Nothing in the console/logs

[TheLastRar]

That suggests that either it hangs before the wrapper starts loading, or the constructor method is being skipped for some reason...

[Fothsid]

Tried CoreCLR method. `SetLog SetSetting SetLog

Initializing plugins... SetSetting Init GS Init PAD Init SPU2 Init CDVD Init USB Init FW Init DEV9 Init Plugin Init CLR Init CLR Runtime Set Dirs PCSX2 Path is /usr/bin/PCSX2
Init CLR Failed At coreclr_initialize - Status: 0x8007001f`

[TheLastRar]

I pushed commit to try and fix that, retry with the latest commit

[Fothsid]

Tried with the latest commit. PCSX2 Path is /usr/bin/PCSX2 Init CLR Failed At coreclr_initialize - Status: 0x80004005

[TheLastRar]

Can you rerun with an environment variable of COREHOST_TRACE=1 and post the resulting logs

[Fothsid]

I'll check this tomorrow, OK? (Not currently at home)

[Fothsid]

There is no logs in terminal or PCSX2's console. https://pastebin.com/KiDDzcdg

[TheLastRar]

It seems the environment variable did not do what I thought it did (It's been a while since I've worked with CoreCLR)

I forgot to mention that CoreFX is also required, you need to build the native components for x86 and the managed components to x64 (x86 build might not complete but we can still use the x64 files as it's mostly AnyCPU)

The contents of bin/runtime/netcoreapp-Linux-Debug-x64/ and bin/Linux.x86.Debug/native/ will need to be copied to the same directory that CoreCLR is (I.e. /home/air/git/ReadyBin.Debug)

You might get a file called System.Private.CoreLib.ni.dll (I don't, but I'm mentioning this anyway), remove it while keeping System.Private.CoreLib.dll

[TheLastRar]

Try running using the env variable PAL_DBG_CHANNELS="+all.TRACE:-FILE.ERROR:-VIRTUAL.all" and post the resulting log

[Fothsid]

emuLog.txt

[Fothsid]

I can't build even managed part of CoreFX. Can you send me your build of x86 version of CoreCLR & CoreFX?

[TheLastRar]

Here is the combined CoreCLR & CoreFX build I use http://www.mediafire.com/file/myd8x4e7eoz2ppn/ReadyBin.Debug.tar.gz/file

Edit: try without the env variable first

[Fothsid]

Well, now it crashes only when I try to start the game.

[TheLastRar]

Do you still get the Init CLR Failed At coreclr_initialize - Status: 0x80004005?

[Fothsid]

No, I don't get this anymore.

[TheLastRar]

What gets logged instead?

[Fothsid]

Without env - edit: emuLog.txt With env - emuLog.txt

[Fothsid]

Fully rebuiled both libraries with the latest commits - no changes, except it doesn't hang anymore when I'm trying to close PCSX2.

[TheLastRar]

Without env, PCSX2 dies in Opening DEV9, there is no CLR_DEV9:PluginInterface Information: 2 : Open, which suggests the crash occurred in the wrapper for some reason.

With env, PCSX2 dies before init completes, I think it gets overwhelmed by the log spam, use PAL_DBG_CHANNELS="+all.TRACE:-FILE.ERROR:-VIRTUAL.all" instead

I pushed a commit that has some extra logging, can you rerun with a build using the latest commit.

[Fothsid]

I used build with latest commits. Without env variable: emuLog.txt With env variable: emuLog.txt (it just hanged, had to kill process.)

[TheLastRar]

Is there a file called DEV9_CLR.log, if there is can you post that as well, I think emulog might be eating messages.

I also has a typo in the new env variable, It's supposed to be PAL_DBG_CHANNELS="+all.TRACE:-FILE.ERROR:-VIRTUAL.all" I've corrected it in my original comments.

[Fothsid]

DEV9_CLR.log

[Fothsid]

With PAL_DBG_CHANNELS="+all.TRACE:-FILE.ERROR:-VIRTUAL.all" it now logs this and crashes properly lol emuLog.txt

[TheLastRar]

The issues appears to occur in managed code. I pushed a commit that has some extra logging to, can you rerun with a build using the latest commit.

The changes I made where to CLR_DEV9_Core, so you will need to rebuild the main plugin.

[Fothsid]

Nothing changed.

[TheLastRar]

No additional information in DEV9_CLR.log?

[Fothsid]

Nope.