#[Compiled Build] LMMS does not load 64 bit VSTs

1 messages · Page 1 of 1 (latest)

runic ginkgo
#

Terminal output when launching a 64 bit VST:

Notice: could not set realtime priority.
gamemodeauto: 
gamemodeauto: 
002c:fixme:winediag:loader_init wine-staging 9.7 is a testing version containing experimental patches.
002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.
00a0:err:hid:udev_bus_init UDEV monitor creation failed
Application could not be started, or no application associated with the specifie
d file.
ShellExecuteEx failed: File not found.

Remote plugin exit code:  1
remote plugin died! invalidating now.
gamemodeauto: 
Remote plugin did not connect.
#

It's running on the X server, with embedding disabled

#

Latest version of Fedora Workstation

#

Also using the winehq-staging package

#

This issue seems to occur beyond wine 9.4

#

32 bit vsts work fine

image.png
runic ginkgo
#

Cmake output for this build:

image.png
dire escarp
#

Update Wine; this was fixed in 9.8 I think

#

Yeah; this was a Wine 9.5 bug that got fixed in 9.8

runic ginkgo
#

No. It's an LMMS bug

dire escarp
#

No, it was a Wine bug

#

Same one that affected two different VST hosts

#

I did my research

#

There was a separate Wine 9 bug on Ubuntu

#

I'm on Arch; we didn't have the same packaging problem

runic ginkgo
#

.... Lost Robot was able to get various versions of WINE 9 working with compiled builds of LMMS

dire escarp
#

Could've been backported, but there was a known bug for three versions

runic ginkgo
#

What was the bug?

dire escarp
#

Wine forgot to search for Linux stub libraries when loading DLLs

#

The whole thing with Wine 9 was bringing more of the Windows things native and calling out to Linux less and less

#

In the process, they got rid of some detection code for finding files that looked like Library.dll.so

#

Hey, guess what that fails to load? 🙃

#

That's why Wine 9.5 broke

runic ginkgo
#

@sour dagger Interesting info

dire escarp
#

They added that back in with Wine 9.8

#

I can go find the commits quick

runic ginkgo
#

I'm assuming different distro's packaging of WINE might've affected it differently

dire escarp
#

From the new code:

        /* File found, but no association. And no other cases fit, this could be a
           unix programs, try running it. We have to do this in a "catch-all" fashion because
           unix program can have any extensions. However, things get more complicated because
           the file we find could be a Windows executable without the proper extensions, it could
           be seen as unexpected if we start it, so we special case it here. */
sour dagger
#

i used wine 9.1 and wine 9.5 and wine 9.8 and lmms worked perfectly fine with all of them, all i had to do was manually fix lmms's faulty wine include path detection

dire escarp
#

I wonder if you had a fixed version of Wine 9.5

#

9.5-9.7 were all broken on original release

#

I agree that there must have been some other issue with them as well packaging-wise, but I never faced that on Arch

#

Wine 9.4 worked, 9.5 broke, and 9.8 worked again

runic ginkgo
#

I'm using the winehq-staging package on Fedora

sour dagger
#

i got the staging version directly from the official winehq repos every time

runic ginkgo
#

That one should be consistent across distros, barring necessary differences for compatibility with each

#

weird

#

The bug that RDR is describing is very real, yet seems nonexistent when taking your simple path corrections into account

dire escarp
#

Huh

runic ginkgo
#

@dire escarp winehq-staging 9.9 does indeed work

image.png
#

I haven't recompiled this build, it's the same one from when I had winehq-staging 9.6 installed

#

My guess at this point is that a combination of wine and lmms are at fault for the bug

dire escarp
#

Makes sense