Get debug working on linux #77

cshingle · 2025-07-06T03:58:30Z

I got debugging working on linux with these changes. Excuse my Kotlin, I have now written like 50 lines of it.

I STRONGLY recommend switching to Doorstop 4.3.0 for Linux. The 4.0.0 version has a hard dependency on a specific version of glibc. The hard glibc requirement will mean that a huge number of Linux users won't be able to use the plugin.

Garethp · 2025-07-06T08:27:29Z

It looks like the only actual changes here are the working directory and referring to Doorstop from Doorstop/Doorstop.dll, right? As for the glibc dependency, that would be in the libdoorstop.so library, right? That file actually comes from Doorstop 4.4

cshingle · 2025-07-06T18:22:42Z

I swapped out the Doortop lib and stuff in my local but didn't include that in the PR. It now makes sense why I am getting a glibc error. Ubuntu 22.04 (the version I am using) ships with GLIBC_2.35. Doorstop 4.4 is compiled against GLIBC_2.38. Doorstop 4.3 is compiled against GLIBC_2.35. Glibc is backward compatible. Using version 4.3 will get you the largest range of compatibility since it will work on any distro using GLIBC_2.35 or greater.

I assumed you where using 4.0.0 because that is what was specified in the .doorstop_version file.

"As for the glibc dependency, that would be in the libdoorstop.so library, right?"
Yes. Conceptually .so files are to Linux what .dll is on Windows. This is only true for stuff written in C, C++ etc. All the DotNet stuff is still .dll on all platforms.

It is possible to get the Linux stuff working without the run.sh file by setting the environmental variables on the GeneralCommandLine object, but progress is being made so that could be a future improvement.

src/rider/main/resources/UnityDoorstop/Linux/run.sh

cshingle · 2025-07-06T19:29:03Z

I had things working at one point but now I am getting the following error. My guess is that I have some kind of version mismatch. Where is the Pdb2Mdb converter from?

Exception loading 0Harmony.dll: System.TypeLoadException: Could not resolve type with token 0100001c from typeref (expected class 'Pdb2Mdb.Converter' in assembly 'pdb2mdb, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null')
  at (wrapper dynamic-method) MonoMod.Utils.DynamicMethodDefinition.System.AppDomain.Load_Patch1(System.AppDomain,byte[],byte[],System.Security.Policy.Evidence,bool)
  at System.AppDomain.Load (System.Byte[] rawAssembly, System.Byte[] rawSymbolStore, System.Security.Policy.Evidence securityEvidence) [0x00000] in <e3b07672ffbd43c1838e1ebbe94cbdf5>:0 
  at (wrapper remoting-invoke-with-check) System.AppDomain.Load(byte[],byte[],System.Security.Policy.Evidence)
  at System.AppDomain.Load (System.Byte[] rawAssembly, System.Byte[] rawSymbolStore) [0x00000] in <e3b07672ffbd43c1838e1ebbe94cbdf5>:0 
  at (wrapper remoting-invoke-with-check) System.AppDomain.Load(byte[],byte[])
  at System.Reflection.Assembly.Load (System.Byte[] rawAssembly, System.Byte[] rawSymbolStore) [0x00005] in <e3b07672ffbd43c1838e1ebbe94cbdf5>:0 
  at HotReload.HotReloader.LoadAssembly (System.Byte[] assemblyData, System.Byte[] assemblySymbols) [0x0011b] in <7f1835aa93524a169c83c4fc07854b13>:0 
  at HotReload.HotReloader.Load (System.IO.FileInfo file, System.IO.FileInfo pdbFile) [0x00075] in <7f1835aa93524a169c83c4fc07854b13>:0 
  at HotReload.Patches.HandleAssemblyLoad (System.Reflection.Assembly& assembly, System.String assemblyFile) [0x00016] in <7f1835aa93524a169c83c4fc07854b13>:0 
  at HotReload.Patches+Assembly+LoadFrom.Prefix (System.Reflection.Assembly& __result, System.String assemblyFile) [0x00000] in <7f1835aa93524a169c83c4fc07854b13>:0 
  at (wrapper dynamic-method) MonoMod.Utils.DynamicMethodDefinition.System.Reflection.Assembly.LoadFrom_Patch1(string)
  at Verse.ModAssemblyHandler.ReloadAll () [0x000ac] in <2c569eda68a7429cafde4b2b1bf7a086>:0 
UnityEngine.StackTraceUtility:ExtractStackTrace ()
Verse.Log:Error (string)
Verse.ModAssemblyHandler:ReloadAll ()
Verse.ModContentPack:ReloadContent (bool)
Verse.LoadedModManager:LoadModContent (bool)
Verse.LoadedModManager:LoadAllActiveMods (bool)
Verse.PlayDataLoader:DoPlayLoad ()
Verse.PlayDataLoader:LoadAllPlayData (bool)
Verse.Root/<>c:<Start>b__10_1 ()
Verse.LongEventHandler:RunEventFromAnotherThread (System.Action)
Verse.LongEventHandler/<>c:<UpdateCurrentAsynchronousEvent>b__28_0 ()
System.Threading.ThreadHelper:ThreadStart_Context (object)
System.Threading.ExecutionContext:RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
System.Threading.ExecutionContext:Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
System.Threading.ExecutionContext:Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object)
System.Threading.ThreadHelper:ThreadStart ()

…ron NuGet

cshingle · 2025-07-06T20:07:22Z

Swapping out the OHarmony.dll for the one my mod is building with fixed the above error. I don't know where your file came from. It is much larger that the one in my PR.
The last change that I made that is not in the PR is swapping out libdoorstop.so with 4.3.0 and updating .doorstop_version to 4.3.0. I can include those as well if you would like.
With this I can confirm that it is working on my system and I can debug my mods.

cshingle · 2025-07-06T20:13:14Z

src/rider/main/kotlin/run/RunConfiguration.kt

                // If we're debugging in Rimworld, instead of /pwd/RimWorldLinux ...args we want to run /bin/sh /pwd/run.sh /pwd/RimWorldLinux ...args
                if (debugInLinux) {
-                    val bashScriptPath = "${Path(pathToRun).parent}/run.sh"
-                    arguments = "$bashScriptPath $pathToRun $arguments"


This line was messing up the commandline.
When running on linux the command should be /bin/sh and the run script command should be the first argument. Any user provided arguments should come at the end. The println I added makes the issue pretty obvious once you look at the output.

It shouldn't have been messing it up. The arguments I had should have ended up as /bin/sh as the command and then ["dir/run.sh", "dir/RimWorldLinux", ...userArgs] as the end result. If you take a look at run.sh:75 it should be taking the first argument in as the executable name, so not passing in the executable would mean that if a user defines arguments in the command line options, it would eat the first argument as the executable name.

Perhaps it was the fact that the executable name shouldn't include it's directory?

To make it work the way you had it you would want
arguments = "$bashScriptPath $arguments"
You already build the run.sh path on this line
val bashScriptPath = "${Path(pathToRun).parent}/run.sh"

The reason I refactored the code some is to do the .split(' ') sooner. I have created a lot of programs that call commandline stuff from Java that needed to run on Windows, Linux and AIX. Splitting on space is fine until some asshole gives you a file path or file name with a space in it.

"Perhaps it was the fact that the executable name shouldn't include it's directory?"
Since we are setting the work directory you could just call run.sh and it would work. It is totally a matter of preference.

I had some trouble getting run.sh executable. Setting it as +x in the resources wasn't preserving the permissions when copying it over and setting the permissions manually in Kotlin wasn't working for me, which is why I'm calling run.sh as an argument to /bin/sh instead.

But yeah, I think moving the .split earlier makes sense, I was going to just look into having getCommandLineOptions return a list directly

Passing a bash script into /bin/sh is a MUCH more portable solution than trying to execute the bash script directly. This was the right call.

"But yeah, I think moving the .split earlier makes sense, I was going to just look into having getCommandLineOptions return a list directly"
I totally support this.

Garethp · 2025-07-06T21:19:56Z

Swapping out the OHarmony.dll for the one my mod is building with fixed the above error. I don't know where your file came from. It is much larger that the one in my PR.

It's probably from an outdated version of Harmony that I've been using in my mods, but it's more of a fallback than a definitive version, especially since different versions of Rimworld need different versions of Harmony. My plugin is actually meant to be scanning the Rimworld Steam Workshops folder for the version of Harmony you currently have installed, and if it finds you have one installed it uses the version of Harmony that is shipped for that version of Rimworld.

Garethp · 2025-07-06T21:23:24Z

buildPlugin.sh

+export Version="2024.1-EAP"
+
+cd "src/dotnet/ReSharperPlugin.RimworldDev"
+FrameworkPathOverride=$(dirname $(which dotnet))/../../../../lib/dotnet/sdk/7.0.202/ dotnet build  ReSharperPlugin.RimworldDev.csproj /property:Configuration=Release


Is this needed? I would have thought that the globals.json in the root dir of this project should have negated the need to do this

Also, does just calling :buildPlugin from gradle without excluding compileDotNet not work? That's how I do it in my CI

Hmm apparently ./gradlew :buildPlugin does work. It didn't when I first setup the script, but that was before you created this branch.
I just got something working and never revised it. I'll push an update.

This file could be removed all together. It is really just documentation at this point.
I am the type of dev that runs git commands in the Intellij terminal rather than use the UI.

Garethp · 2025-07-07T00:03:28Z

I'll test this locally sometime tomorrow and look at merging/releasing in the next week, thanks for the contribution :)

cshingle · 2025-07-09T05:41:49Z

Swapping out the OHarmony.dll for the one my mod is building with fixed the above error. I don't know where your file came from. It is much larger that the one in my PR.

It's probably from an outdated version of Harmony that I've been using in my mods, but it's more of a fallback than a definitive version, especially since different versions of Rimworld need different versions of Harmony. My plugin is actually meant to be scanning the Rimworld Steam Workshops folder for the version of Harmony you currently have installed, and if it finds you have one installed it uses the version of Harmony that is shipped for that version of Rimworld.

Since OHarmony.dll is a dotnet dll you should be able to use the same file on all platforms. The better solution may be to create a new resource folder for them and name them based on the version of Rimworld. Then add something that reads the Version.txt file and selects the correct OHarmony.dll version and copies it.

Unparticular · 2025-08-08T12:15:38Z

I'll test this locally sometime tomorrow and look at merging/releasing in the next week, thanks for the contribution :)

Hi, not to rush you or anything but is there some reason this hasn't been merged in yet? I'm just asking as it's been almost a month since your last message.

Get debug working on linux

69bfa86

cshingle commented Jul 6, 2025

View reviewed changes

src/rider/main/resources/UnityDoorstop/Linux/run.sh Outdated Show resolved Hide resolved

caleb added 2 commits July 6, 2025 14:46

Add buildPlugin.sh and remove append from tee

5b2f018

Swap out OHarmony.dll for Lib.Harmony.Ref.2.3.6/ref/netstandard2.0/ f…

3b2b3fe

…ron NuGet

cshingle commented Jul 6, 2025

View reviewed changes

Garethp reviewed Jul 6, 2025

View reviewed changes

Simplify buildPlugin.sh

0ba51fb

cshingle mentioned this pull request Jul 8, 2025

Linux Support #75

Closed

Get debug working on linux #77

Are you sure you want to change the base?

Get debug working on linux #77

Uh oh!

Conversation

cshingle commented Jul 6, 2025

Uh oh!

Garethp commented Jul 6, 2025

Uh oh!

cshingle commented Jul 6, 2025

Uh oh!

Uh oh!

cshingle commented Jul 6, 2025

Uh oh!

cshingle commented Jul 6, 2025

Uh oh!

cshingle Jul 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Garethp commented Jul 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Garethp commented Jul 7, 2025

Uh oh!

cshingle commented Jul 9, 2025

Uh oh!

Unparticular commented Aug 8, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cshingle Jul 6, 2025 •

edited

Loading