How to create a cross-platform M4L device on Mac with custom externals that depend on DLLs on Windows

Diemo Schwarz's icon

Hi, we know from this tutorial that it is possible on a Mac to create a cross-platform M4L device that will automatically include Mac .mxo and Windows .mxe64 externals.
But how should one proceed if some of the Windows externals depend on custom DLLs (e.g. Spat5 or Mubu)?
How to include them in a way they will be found on Windows?

Another related question is the dreaded Visual Studio redistributable DLL both the above packages depend on. This one seems to be needed to be installed before by the user from https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0 and it does not seem to be possible to include it in the device.

Any insights or pointers to documentation are very welcome.
Cheers...
...Diemo

11OLSEN's icon

Try adding the dll files manually to the project before freezing. The other dependency is like it is. You can only inform the user about it i would say.

Diemo Schwarz's icon

Hi Olsen, the DLLs in the device seem not to be found by Max, there is always the dreaded error 126.
This is all very opaque. Do you know a way to get Windows to tell you where and what exactly it was looking for?

11OLSEN's icon

On WIN, where have the dlls to be located to make your externals work in an unfrozen device?

Diemo Schwarz's icon

We're not using Windows much, but it seems the DLLs are found when they are in the package's support folder.

11OLSEN's icon

I was always freezing on WIN so I can't tell much about Mac but when I had dll dependencies for the win external they had to be in the same location as Max.exe in normal operation. Like mentioned, it worked in a frozen device on other maschines just by adding the dlls to the root path of the project before freezing the device.
You just need to find out where your externals are expecting the dependencies.

11OLSEN's icon
Diemo Schwarz's icon

thanks for all the hints! we took the route of static linking all DLLs (except the VS one), to avoid the problem...