follow up on the thread with current installation success reports
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
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 
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
Sorry to bust in to this thread like the proverbial Kool-Aid man, Iām coming from the Rhino on Linux thread.
Iām running OpenSUSE Tumbleweed with KDE-Plasma (Wayland) and a Bottles frontend. I have had a super easy time getting MoI3D to run using Proton GE (I use MoI as a first step in my Rhino pipeline) and then quickly ran into why Rhino gets a āgarbageā rating on the WineHQ meter.
I was able to get through the install, but Rhino fails to communicate with its license server on load. The specific error is: err:find_forwarded_export module not found for forward āicuuc68.u_charsToUChars_68ā. This seems like an issue with the Windows ICU library version, but I havenāt had any luck with finding a version that works.
Iāve tried Proton GE (ge-proton10-15), soda (soda-9.0-1) and Wine (sys-wine-10.0) with no luck. Iāve been using Windows Version 10 (and tried 11 a few times as well). From a dependencies standpoint I installed vcredist2022 and dotnetcoredesktop8.
Unfortunately I donāt see any guides on systematically approaching the building of a Wine configuration. I used Process Monitor to get a list of all the DLLs being used by Rhino and Rhino + Grasshopper, but taking that information and transforming it into a Wine configuration seems like a guess and check procedure rather than something a bit more sane.
1 Like
not a kool-aid at all, thanks for the detailed report. if itās just icu DLLs that are missing it looks like you can download them from the official project website: Release ICU 68.2 Ā· unicode-org/icu Ā· GitHub (one called icu4c-68_2-Win64-MSVC2019.zip). Itās not ideal to use DLLs instead of winetricks, but maybe it will work - I imagine that dropping them into rhinoās app folder (next to Rhino.exe) or into drive_c/windows/system32 of the bottle should work.
It looks like in bottles you set overrides to native,builtin (Settings ā DLL Overrides ā add icuuc68, icuin68, icudt68 = native,builtin). Or via env once for testing `WINEDLLOVERRIDES="icuuc68,icuin68,icudt68=n,b" wine Rhino.exe`
If you see a different ICU major (e.g., icuuc72) in logs, match that exact major instead. Rhino versions hard-link to a specific ICU major.
strangely enough, I donāt see any icu DLLs in my .wine folder, so not sure if thatās really the core issue - if this doesnāt work, could you send us full wine logs (can share it through pastebin.com or similar)?
in general, one quick fix is often using wine-staging instead:
`zypper install wine-staging`
also are you testing this on rhino 7? nobody got rhino 8 to work with wine yet as far as i know
if you want to try plain wine instead of bottles these are the steps that worked for me (2 years ago):
winetricks -q corefonts pptfonts dotnet48 vcrun2005 vcrun2010 vcrun2013 vcrun2019 vcrun6 vcrun6sp6 gdiplus dxvk
wine winecfg -v win10
wine Downloads/rhino_en-us_7.32.23221.10241.exe
also on kde wayland, but arch packages:
multilib/wine
extra/vkd3d
extra/wine-gecko
extra/wine-mono
multilib/lib32-vkd3d
aur/dxvk-bin
aur/winetricks-git
3 Likes
Thanks, I should have some time this weekend to take a proper look at your suggestions. Iām going for broke on Rhino 8, Iād rather run inside a VM then have to drop back to V7.
Works great with QEMU/KVM on my Kubuntu machine (and GPU PCI passthrough for native drawing speeds with Rhino, including Raytraced and Rhino Render usage).
I havenāt gotten Rhino 8 working through Wine either.
2 Likes
yeah, you are entering an unchartered territory trying to get rhino 8 to run under wine, nobody has managed to get it to work so far (although some time has passed since it was last discussed)
by the way looks like rhino 9 is coming out soon* as well, so may be worth trying it out then too/instead
* I donāt know when Rhino 9 will be officially released, just saw a banner saying that WIP version is already available
** looks like some users have tried to run Rhino 9 on wine already, sadly to no avail
Hahahaha.
Edit:
McNeel Devs: not mocking you. Just amused, as someone who has, by this remark from someone who has apparently not lived through 7 versions of Rhino.
If you have a Rhino 8 license why wait? Just try with the WIP.
1 Like
Any tips on how you did the GPU PCI passthrough? I have some trouble with this
Thank you
I am using primarily Kubuntu (but on my M2 Max Iām using Asahi Linux, which is Fedora), but the most info I gleaned from PCI passthrough via OVMF - ArchWiki
. It also meant I had to tweak some steps to work for my case.
First figure out PCI IDs and set up GRUB to pass on as kernel parameters ( PCI passthrough via OVMF - ArchWiki )
I set
GRUB_CMDLINE_LINUX_DEFAULT="amd_iommu=on iommu=pt vfio-pci.pids=10de:2230,10de:1aef
Youāll need to find out the correct IDs for your case. Iām using amd_iommu because I have an AMD CPU. Youāll do something different in case you have an Intel CPU. The vfio-pci.pids part stays the same though.
Then I make sure through modprob that vfio-pci is loaded ( PCI passthrough via OVMF - ArchWiki ). I set /etc/modprobe.d/vfio.conf to have the content softdep nvidia pre: vfio-pci.
Then when I create the virtual machine for QEMU/KVM I choose to add the PCI device I designated for passthrough.
Further I use Looking Glass (https://looking-glass.io) as the client to my virtual machine.
Note that to have the PCI passthrough work properly the GPU you pass through needs to be hooked up to a monitor. I have my computer on a TV with both GPUs connected to the HDMI ports. When I start my virtual machine I briefly switch input source so I can see how I log in. After that I use the Looking Glass client, and naturally switch input source back to my host GPU.
3 Likes
Thank you very much for the help. It sounds like some work but i will try!
1 Like
Ahoy hoy,
Has anyone here tried implementing GPU pass-through for WinBoat? Iām aware itās still not at full release yet and being actively worked on, but I was wondering if anyone has been got it work work in any manor.
Current renders on my WinBoat Rhino8 install takes upwards of 40 minutes, where previous renders would take only 1-1.5 minutes. If possible Iād like to be able to take advantage of the hardware I have.
Iāve also noticed drawing/pane render speed (even wireframe) has quite a bit of lag, but I figure the two issues are related.
Otherwise it seems to work pretty well after I passed the correct folder structures through for it to access them! 
Heya, last I looked (2 - 3 weeks ago, when I installed it) according to the developers of winboat GPU passthrough was a known missing feature. If theyāve fixed that that quickly let me know because that would be a big deal!
Iāll be checking every day 
The second thatās solved (reliably), my workflow will go back to its previous level and Iāll become the bottleneck again. I saw the tweet they put out about OpenGL.
One of the discussions: [Feature] GPU Acceleration Ā· Issue #239 Ā· TibixDev/winboat Ā· GitHub
1 Like
@Sam49 if winboat is unable to pass gpu through look into virt-manager or plain qemu, which supported it since about 2013. This winboat discussion is fairly popular and somewhat recent, so itās possible that they will add it eventually (Iām really not sure why itās causing problems to begin with), but if you are in a hurry libvirt/qemu is the way to go.
1 Like
Iām really curious how claude code with fare against this problem - just had it solve something complex after giving it full system access (sudo password, but in a qemu/kvm environment), which it used quite cleverly. I was previously only using it from the browser and difference is noticeable in terms of scope and depth of itās context. Iād hope to see some interesting manipulations of wine registry and DLL overrides. Just going through architecture exams right now, so donāt have enough time to invest, but itās there on the list