Rhino on Linux - Technicalities

Rhino
1

follow up on the thread with current installation success reports

3 Likes
2

Thanks @Winer for splitting this out. If you’re new here - we were discussing not wanting to fill up the old Rhino on Linux thread with the gory details of failed installations, bugs, etc. I hope we can all share our technical matters here and simply report back to that thread with our successes.

For example, hooking on Winer’s message in the previous thread regarding getting R8 running on Linux. I am getting the same stack overflow he is except mine is a different size (4736). I wonder if there are any clues there… I didn’t install .net 4.8 this time, just 7.0 from the exe. The installer really raised a fuss when I didn’t install all the VC Runtimes, but I did skip vcrun2019 for vcrun2022, since that’s the newer version of the same thing…

It does look to me from the bug Winer posted that, regardless of whatever the next hurdle is and regardless of whether the wine devs marked the bug as fixed, the prior one that people were running into that prevented the installer from proceeding has been mooted.

To summarize - Winer and I have both had the R8 installer complete successfully. I had to install MS Edge in wine before using the installer for it to not hang there. Otherwise I used the instructions for installing R7 from RNA Design Hub that I’ve used to successfully install R7, and also added to the winetricks command to install dependencies vcrun2022 and dotnet7. I’ve also had some people recommend adding dxvk.

Onward and upward!

Edited to add: the size of my stack overflow reduces to the same as Winer’s from the prior thread when I do a fresh installation of all the dependencies, etc. But I also tried safemode and that doesn’t work. So it’s something in the core function of the program.

2 Likes
3

You are right that the previous WldpQueryWindowsLockdownMode bug has been solved, somewhere between wine 9.10 and now, which is very very nice and installer gets to the end like you said.

In terms of this stackoverflow after a few backs and forths with wine debug options and ai I got absolutely nowhere, so I switched to winedbg instead - this was more helpful and pointed to some issue with “.NET Core 7.0.0 runtime initialization”.

$ winedbg ~/.wine/drive_c/Program\ Files/Rhino\ 8/System/Rhino.exe
Wine-dbg>set $BreakOnFirstChance=1
Wine-dbg>c

here is backtrace from first exception caught while calling .NET libraries

Backtrace:
=>0 0x006fffffc0d127 in kernelbase (+0xd127) (0x0000000011bc09)
  1 0x006ffff7eae349 in coreclr (+0x1de349) (0x0000000011bc09)
  2 0x006ffff7dd1fd4 in coreclr (+0x101fd4) (0x0000000011bc09)
  3 0x006ffff7dd278d in coreclr (+0x10278d) (0x0000000011bc09)
  4 0x006ffff7e25fca in coreclr (+0x155fca) (0x0000000011c031)
  5 0x006ffff7d8c64d in coreclr (+0xbc64d) (0x0000000011c031)
  6 0x006ffff7dfa753 in coreclr (+0x12a753) (0x0000000011c031)
  7 0x006ffff7dfa6fa in coreclr (+0x12a6fa) (0x0000000011c031)
  8 0x006ffff7dfa638 in coreclr (+0x12a638) (0x0000000011c031)
  9 0x006ffff7e118fa in coreclr (+0x1418fa) (0x0000000011c031)
  10 0x006ffff81e3d97 in hostpolicy (+0x3d97) (0x0000000011c180)
  11 0x006ffff81f8468 in hostpolicy (+0x18468) (0x0000000011c300)
  12 0x006ffff82700c6 in hostfxr (+0x100c6) (0x0000000011c300)
  13 0x006ffff826a1fc in hostfxr (+0xa1fc) (0x0000000011c300)
  14 0x006ffffc506494 in rhinocore (+0xa56494) (0x0000000011c300)
  15 0x006ffffc506b85 in rhinocore (+0xa56b85) (0x0000000011c420)
  16 0x006ffffc50677b in rhinocore (+0xa5677b) (0x0000000011c760)
  17 0x006ffffc506133 in rhinocore (+0xa56133) (0x0000000011c760)
  18 0x006ffffc0f2a0c in rhinocore (+0x642a0c) (0x0000000011c760)
  19 0x006ffffc0eb85b in rhinocore (+0x63b85b) (0000000000000000)
  20 0x00000140002305 in rhino (+0x2305) (0x0000000011e980)
  21 0x00000140002d32 in rhino (+0x2d32) (0000000000000000)
  22 0x006fffffec4949 in kernel32 (+0x14949) (0000000000000000)
  23 0x006ffffff3fd93 in ntdll (+0xfd93) (0000000000000000)
0x006fffffc0d127 kernelbase+0xd127: addq $0xc8, %rsp

then next exception, which I suspect is this stackoverflow

Backtrace:
=>0 0x006fff9835e5fd (0x00000000022030)
0x006fff9835e5fd: callq *0x1237dd(%rip) -> 0x0000010085a220 system.private.corelib+0x44a220

it points to System.Private.CoreLib library, which contains low-level code for basic types (like strings or objects), memory management, etc.
so it makes me think that the reason Rhino 8 doesn’t run is because it switched from .Net Framework (versions before .Net 5) to .NET core (versions after .Net 5)

now if that’s true, perhaps McNeel could introduce a “compatibility mode” for Rhino 8, so it loads using legacy .Net Framework
but that would miss all the fun in trying to get .Net core to work of course :sweat_smile:

maybe obvious, but I learned that .Net core doesn’t rely on wine-mono, but is a self-contained executable running directly under wine

more could be digged out, .net core is open-source, so could use debug symbols to maybe finally resolve it, but I’ve run out of time for today

compiling wine from source should prove useful as well, for anyone wanting to try that:

git clone https://github.com/wine-mirror/wine.git
cd wine
./configure \
  --prefix=/opt/wine-debug \
  --enable-debug-symbols \
  --disable-strip \
  --without-tests
make -j$(nproc)
sudo make install

then likely

export PATH=/opt/wine-debug/bin:$PATH
export LD_LIBRARY_PATH=/opt/wine-debug/lib${LD_LIBRARY_PATH:+":$LD_LIBRARY_PATH"}

and reintalling rhino in new .wine prefix this maybe will yield more detailed information when repeating above winedbg steps

also I’ve try dabbling with ~ $ ulimit -s unlimited and WINE_STACK_SIZE=33554432, but nothing changed

1 Like