How to create a cross-platform M4L device on Mac with custom externals that depend on DLLs on Windows
Jun 07 2021 | 7:51 pm
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
- Jun 07 2021 | 8:45 pmTry 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.
- Jun 10 2021 | 7:44 amHi 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?
- Jun 10 2021 | 8:32 amOn WIN, where have the dlls to be located to make your externals work in an unfrozen device?
- Jun 10 2021 | 9:12 amWe're not using Windows much, but it seems the DLLs are found when they are in the package's support folder.
- Jun 10 2021 | 10:26 amI 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.
- Jun 10 2021 | 10:35 am
- Jun 16 2021 | 10:36 amthanks for all the hints! we took the route of static linking all DLLs (except the VS one), to avoid the problem...
