Error connecting to process / Linking Issues on Arch Linux

[huyderman]

I got the following error in STDERR when trying to authorize RimVibes on Arch Linux:

/home/huyderman/.local/share/Steam/steamapps/workshop/content/294100/2062062427/Executables/Decompressed/Linux_x64/Core: symbol lookup error: /home/huyderman/.local/share/Steam/steamapps/workshop/content/294100/2062062427/Executables/Decompressed/Linux_x64/System.Net.Http.Native.so: undefined symbol: curl_multi_wait

After authorizing Spotify, RimVibes ended up in the "Disconnected (Process not started)" state.

I've got curl, libcurl-compat, lib32-curl and libcurl-compat packages installed, so the library should be available. I also installed the dotnet-runtime and dotnet-sdk packages make sure all the dependencies should be present.

I've also tried deleting the mod and it's folder and reinstalling it.

I suspected there was some linking issues with the bundled dotnet core, so I tried force the native installed version (from dotnet-runtime above) with LD_LIBRARY_PATH="/usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.3". This seems to work as I now manage to connect to Spotify.

[Epicguru]

Thank you for the report. I've only tested the Linux version on Debian, so that probably contributes to some of the buggyness. There are a lot of issues that arise from both try to authorise and then run a .net core process from within a Mono .net framework game.

If the mod fails to launch the program, your best option is to manually run it. The executable is found at ModFolder/Executables/Decompressed/Linux/Core.

Running that manually once the game is running should cause it to automatically connect to the mod.

I know this isn't ideal, but debugging for Linux is quite hard since I can only compile on Windows. If I find more time I will try to smooth out the bugs.

[huyderman]

Yeah, it seems finicky.

Since the dotnet core distribution packaged with the mod apparently doesn't include all its dependencies and dynamic link to system libraries, it will be sensitive to the versions of those dependencies in the underlying system.

It might be better to try to detect if a system version of dotnet core is available, and prefer to use that.

An alternative is to simply list it as an external dependency, and just use the system one, as packages for dotnet core should be available for all major distributions. Any Linux gamer who uses mods with RimWorld is likely savvy enough to install an external dependency. ;)

https://docs.microsoft.com/en-us/dotnet/core/install/linux

[Epicguru]

Are you sure that the packaged .NET Core runtime doesn't have all dependencies? I installed the mod on a computer with a fresh Linux installation and it worked without having to install any additional runtimes.

I agree that most people playing on Linux are prepared to install an external dependency, but technically it is against the Rimworld mod terms of service: all mods must work 'as is' without requiring installation of external software.

I'm also fairly sure that to target an external dependency and fall back to a packaged runtime I would need to distribute 2 copies of the linux build, which would increase the mod size even more (it's already at 50MB and it doesn't include Mac support yet).

Once I get some more time I'm probably going to completely re-write the cross platform system and get everything working without users having to mess around with dependencies.