Cannot load library C:\Program Files\LMMS\plugins\carla*.dll on Windows

[stevenwdv]

Bug Summary

I tried to use the Carla plugins, but they do not load.

Disclaimer: I don't really know much about the plugin and am new to LMMS.

Steps to reproduce

• Start LMMS 1.3.0-alpha.1 via cmd

Expected behavior

According to the release notes Carla should work now, but it doesn't (also when I add Carla.lv2 to my path).

I downloaded 64-bit Carla from the link at the bottom of https://kx.studio/Applications:Carla and unzipped it somewhere. Do I need to do more to make it work? Do you even need to download it separately?

Actual behavior

Carla plugins are not listed, and in the console I get:

Cannot load library C:\Program Files\LMMS\plugins\carlapatchbay.dll: The specified module could not be found.
Cannot load library C:\Program Files\LMMS\plugins\carlarack.dll: The specified module could not be found.
Cannot load library C:\Program Files\LMMS\plugins\carlabase.dll: The specified module could not be found.

This is Win32 error code 0x0000007E (126): ERROR_MOD_NOT_FOUND.

When looking at API calls we can see that LoadLibraryW("C:\Program Files\LMMS\plugins\carlapatchbay.dll") indeed fails (returns NULL) and sets the error code to the value above. I verified that this dll does actually exist at this path. Apparently this error code can mean that a dependency was not found, but carlapatchbay.dll depends on:

libgcc_s_seh-1.dll
lmms.exe
carlabase.dll (this depends on carla.dll but that file should exist too)
kernel32.dll
MSVCRT.dll
libstdc++-6.dll
Qt5Core.dll
Qt5Gui.dll

which do all exist.

Affected LMMS versions

LMMS 1.3.0-alpha.1

[softrabbit]

This might help, in addition to adding Carla.lv2 to my path I moved carla.dll from plugins/optional to plugins and now LMMS seems to mostly find the DLLs (maybe 1 out of 5 times it fails). Found that at #4654 (comment)

(Can't use it though, LMMS freezes and Windows kills it if I try to put a Carla rack or patchbay on a track. But that might be my box that's too slow.)

[DreadDendy]

Hello. I have found that this bug is actually with Carla 2.3.0,
https://github.com/falkTX/Carla/releases/tag/v2.3.0

For the version 2.2.0,
https://github.com/falkTX/Carla/releases/tag/v2.2.0
there is no such problem, it works as intended (also no need to move .dll files).

I hope this observation will be useful.

[tresf]

Hello. I have found that this bug is actually with Carla 2.3.0, https://github.com/falkTX/Carla/releases/tag/v2.3.0

For the version 2.2.0, https://github.com/falkTX/Carla/releases/tag/v2.2.0 there is no such problem, it works as intended (also no need to move .dll files).

I hope this observation will be useful.

Confirmed. @falkTX any idea how to get this working with the latest?

[falkTX]

I guess it is related to me trying to make use of stack boundary checks, but I am removing that for next 2.5.5 release.
There are early builds in a recent build https://github.com/falkTX/Carla-Releases/actions/runs/5059054702 if you can try would be most welcome.

[tresf]

@falkTX thanks for the quick reply. I tested 2.5.5 from the artifacts and it still does not load. Any other ideas?

[falkTX]

why doesnt it load? I cant just guess it

[tresf]

why doesnt it load? I cant just guess it

• It works for 2.2.0. By "works", I mean LMMS finds carla.dll and the plugin shows up in the sidebar.
• When I say "it doesn't load", I mean, LMMS shows the following message for 2.3.0, 2.5.5 and does NOT show in the sidebar:

  Cannot load library C:\Program Files\LMMS\plugins\carlapatchbay.dll: The specified module could not be found.
  Cannot load library C:\Program Files\LMMS\plugins\carlarack.dll: The specified module could not be found.
  Cannot load library C:\Program Files\LMMS\plugins\carlabase.dll: The specified module could not be found.

You helped us get this working here:

• Switch to Xenial build environment  #4813 (comment)

... and then again here:

• Add Carla support for Windows #5713

If you don't have any ideas, that's fine, we'll just ask people to use 2.2.0 until someone can dive deeper.

[falkTX]

From what I can read on the other tickets, the step to get it to work was to reuse the lv2 carla.dll.
That dll only exposes LV2 symbols needed to get LV2 functionality working, so yeah this cannot work. It might have worked before because I forgot to strip the LV2 dll symbols but this was always wrong approach.

So the #5713 needs to be partially reverted to use libcarla_native-plugin.dll on Windows just like in all other OSes.

[falkTX]

By the way, latest/next carla has a cmake setup file now, which allows to build the host related tools. (it is even compatible with MSVC now)
See https://github.com/falkTX/Carla/tree/main/cmake

It does not build the full frontend though, and I still need to add the libcarla_native-plugin.dll target there. If it is something that could be useful here, let me know and I can add the needed bits to build that DLL too.

That said, I think I should be able to fix things enough to make this work again.
On LMMS side at least there are 2 things to do:

1. use libcarla_native-plugin.dll again instead of carla.dll
2. move carlabase.dll into the LMMS root dir, right now it is installed in the plugins subdir but that does not work on Windows

[falkTX]

ok I am able to get things to work again.

Just a few easy steps:

1. Download latest build from https://github.com/falkTX/Carla/actions/workflows/release.yml (or 2.5.5, to be released later today)
2. Copy/extract carla.lv2/resources into %programfiles%/LMMS/resources
3. Copy carla.lv2/libcarla_utils.dll into into %programfiles%/LMMS/
4. Maybe needed? to move carlabase.dll out of LMMS plugins dir into the root, not sure if it is a wine thing or not though

That should do it.
I imported the fix regarding current-working-dir in falkTX/Carla@43c3478 so you can remove it now if the min required Carla version on Windows becomes 2.5.5
Starting Carla this way was having it load LMMS Qt stuff, which is quite a different build and lead to random crashes, corrected in falkTX/Carla@214a5aa

PS: I only tried this via wine, not on a real Windows system. But should be the same in the end.

[tresf]

PS: I only tried this via wine, not on a real Windows system. But should be the same in the end.

Thanks. I tried a few variations of this on Windows proper:

• Step-by-step
• MKLINK /D attempts (Windows' flaky symbolic link support)

Unfortunately, I still can't get the plugin to load. Based on your comments, I assume it's a DLL search order (or DLL search location issue), but I'm not sure how to get this working.

Here are my current steps on Windows (click to expand)

Click to expand steps

1. Download Carla win64 artifact @ 123ab13.
2. Extract Carla to C:\Carla-2.6.0-alpha1-win64\
3. Perform above steps, quoting:

   1. Copy/extract carla.lv2/resources into %programfiles%/LMMS/resources
   2. Copy carla.lv2/libcarla_utils.dll into into %programfiles%/LMMS/
   3. Maybe needed? to move carlabase.dll out of LMMS plugins dir into [%programfiles%/LMMS/], not sure if it is a wine thing or not though

4. Start LMMS (optionally, start from Command Line to see output)

I tried a few other combinations too.

One thing I noticed when using depends.exe on our carlabase.dll is that the Parent Import ("PI") column is red for carla_get_library_folder().

Carla 2.5.5-snapshot:

Carla 2.2.0:

My gut instinct is that this symbol is the root of the problem. I took a quick glance at the Carla project and didn't notice any immediate changes to this API call though so this is just a blind guess. 🍻

[falkTX]

this is linking against libcarla_native-plugin.dll correct? and that is what you end up using, right? (not the lv2 carla.dll which will NOT contain the needed symbols)

the libcarla_native-plugin.dll should have the functions needed as can be seen by https://github.com/falkTX/Carla/blob/hotfix-2.5/source/plugin/symbols/carla-native-plugin.def

[falkTX]

Trying this myself in Wine, doing these exact steps:

1. Downloaded and installed https://github.com/LMMS/lmms/actions/runs/5173021850 mingw64
2. Downloaded https://github.com/falkTX/Carla/actions/runs/5176690011 win64 zip
3. Copied carla.lv2/libcarla_utils.dll and carla.lv2/libcarla_frontend.dll into %programfiles%/LMMS/
4. Copied the folder carla.lv2/resources as %programfiles%/LMMS/resources
5. Copied Carla/libcarla_native-plugin.dll into %programfiles%/LMMS/ and renamed it carla.dll

works here.
text looks weird due to some wine oddities, just ignore it.

[tresf]

Copied Carla/libcarla_native-plugin.dll into %programfiles%/LMMS/ and renamed it carla.dll

Oh... this step was mentioned, but missing. I'll re-try.

this is linking against libcarla_native-plugin.dll correct? and that is what you end up using, right? (not the lv2 carla.dll which will NOT contain the needed symbols)

Unfortunately, we still use carla.dll on Windows per #4654 (comment), (via 1cce006).

We can absolutely switch it back but it will break anyone upgrading. Fortunately, I don't think this combination is common enough to worry about, so the project shouldn't get much pushback on it.

I'll re-test now.

[falkTX]

I think it is better to change it, gets quite confusing otherwise.

Since I have removed the "carla releases" repo and made these release-style downloads part of the main repo, I expect more people to pick this up if it becomes easier to manage.
Maybe I should add a "mini redistributable pack" artifact that contains only the needed pieces for LMMS ready to drag&drop...

[tresf]

@falkTX,

So I was really struggling with the .lv2 folder throwing python errors so out of curiosity, I did the following:

1. Added C:\Carla-2.6.0-alpha1-win64\Carla (NOT Carla.lv2!) to PATH environment variable
2. Created a symbolic link carla.dll -> libcarla_native-plugin.dll

   REM NOTE: MKLINK LINK TARGET is backwards from POSIX, destination is first!!!!
   mklink "C:\Carla-2.6.0-alpha1-win64\Carla\carla.dll" "C:\Carla-2.6.0-alpha1-win64\Carla\libcarla_native-plugin.dll"

3. Start LMMS, everything works

Any concerns with the above?

[falkTX]

adding to the PATH shouldnt be needed or recommended.

[falkTX]

let me do a quick try on Windows, to see what kind of errors appear...

[tresf]

adding to the PATH shouldnt be needed or recommended.

This is to avoid steps that mutate our install directory.

[falkTX]

adding to the PATH shouldnt be needed or recommended.

This is to avoid steps that mutate our install directory.

by mutating the entire windows system? the native-plugin DLL is always needed because a library links against it, the proposed workaround doesn't sound very sane to me.

LMMS could just setup Carla on Windows to build the extra tools, something like...

include(FetchContent)
FetchContent_Declare(CarlaUtils
  GIT_REPOSITORY https://github.com/falkTX/Carla.git
  GIT_TAG v2.5.5
  GIT_SHALLOW TRUE
)
FetchContent_MakeAvailable(Carla)

(this wont work as-is right now, just a proposal/idea for future)

I tried copying stuff into the LMMS dir on a real Windows system just now. No errors appear, it works on the first try.

[tresf]

by mutating the entire windows system? the native-plugin DLL is always needed because a library links against it, the proposed workaround doesn't sound very sane to me.

I understand the concerns.

Unfortunately, until Carla or LMMS provides a reliable search location, LMMS needs a way to find this file. It's how we tackled this in #5713 and -- in my experience -- it's quite common for software to use this. Windows looks for DLLs in the following search order:

1. The %SystemRoot%\SYSTEM32 directory.
2. The .exe file directory.
3. The current directory.
4. The %SystemRoot% directory.
5. The directories in your Path.

... so PATH is often considered a sane location, despite it's brute-force nature.

Another possible solution is to provide a settings screen for this like we do for VSTs and things, or a custom environment variable, but I wanted to decrease the scope.

There's also the possibility of having Carla as an installable desktop application, (then we'd look for it in some reliable locations) but that would be even more scope, so PATH is a quick way to get it working that users tend to understand, and one which is easy to cleanup if it causes problems.

[tresf]

LMMS could just setup Carla on Windows to build the extra tools, something like...

Yeah, I think this is the best long-term approach, but we'd probably want to build and bundle it for all systems if that's the case.

[falkTX]

ok so it is a matter of reducing scope. even if we had Carla in a known location, that doesnt help the case of needing libcarla_native-plugin.dll along-side lmms.exe.

simplest method I see here, without having to resort to a full installer, is to have Carla write to the windows registry in a predefined path what was its last known location. so users would run the standalone once, and after that LMMS would try to find it via registry key.
that would still be windows specific, but that is what this ticket is all about anyway. on linux and macOS we have proper defined locations where applications go, it is just windows needing special methods.

[tresf]

simplest method I see here, without having to resort to a full installer, is to have Carla write to the windows registry in a predefined path what was its last known location. so users would run the standalone once, and after that LMMS would try to find it via registry key.

Yes, however, that will require the user to run carla at least once, then start LMMS, since the desktop installer is distributed as a .zip.

that would still be windows specific, but that is what this ticket is all about anyway. on linux and macOS we have proper defined locations where applications go, it is just windows needing special methods.

Well, Windows has defined locations for apps too, I just think it's just more culturally acceptable on systems like Mac to expect users to drag-and-drop software into the Applications folder from a zip file.

The same could be argued for Windows, we could expect a drag-and-drop to C:\Program Files\<Carla, etc>, but this is so uncommon to Windows users, that -- in my experience -- it's more common to just use C:\<Carla, etc> for manually-installed apps.

I could offer to write a Windows desktop installer/uninstaller for Carla (I use makensis, which is available for Windows, Linux and MacOS hosts to build Windows installers) but for personal reasons, I've had to become less involved with LMMS which is why I haven't volunteered myself up to this point. If you'd like something like this, I can probably write it up in a few days, I'd just have to learn how to script and call the .nsi from the build environment. Note, I've learned the hard way that I don't really like CMake's nsis integration, so I'd likely treat it as a .nsi.in file and configure/call it manually from the build environment.

[tresf]

I could offer to write a Windows desktop installer/uninstaller for Carla

This could also help with some redundant files and reduce the download size.

[falkTX]

Writing an installer is not a problem, I have done it quite a few times.
It is more about maintenance and support, I simply dont use Windows anymore so the installers become bothersome. Everytime I need to do something on Windows the zip method is just faster and fully self-contained as I can simply delete the folder and be done with it.

If doing a Windows installer for Carla, I would need volunteers to actively test it, specially important for new versions where a couple of deep things change (like v2.6 introducing libcarla_frontend)

[tresf]

that is what this ticket is all about anyway

Not to start another argument here, but the ticket is due to a historical decision to use carla.dll, which no longer contains the symbols for carlabase.dll, so #6726 fixes it, and we just change our existing procedures to use Carla instead of Carla.lv2. :D

If doing a Windows installer for Carla, I would need volunteers to actively test it, specially important for new versions where a couple of deep things change (like v2.6 introducing libcarla_frontend)

I was thinking of this as well and didn't mention it... I didn't mean to minimize this effort. 🍻

[falkTX]

that is what this ticket is all about anyway

Not to start another argument here, but the ticket is due to a historical decision to use carla.dll, which no longer contains the symbols for carlabase.dll, so #6726 fixes it, and we just change our existing procedures to use Carla instead of Carla.lv2. :D

while not the best, that is surely the easiest and fastest way at the moment.

[tresf]

while not the best, that is surely the easiest and fastest way at the moment.

I've tested our artifact from #6726 with C:\Carla-2.6.0-alpha1-win64 added to PATH and it works now without the carla.dll workaround. I'm happy to resurrect this PATH conversation in the future though. Thanks for the help! I'll link the convo to our dev channel on Discord for others to chime in on, but this bug will auto-close once #6726 is merged.

Here's our updated installer:
https://github.com/tresf/lmms/actions/runs/5181060447#artifacts