Right way in include dylib/DLLs for installer

[aaronleese1]

Hey all -

Quick question: When including dynamically linked libraries in installers, what is considered best practice nowadays?

Here is my guess … but let me know what might be better:

Mac:

• include all dylibs in the bundle, usually @app/Frameworks or something similar
• set @rpath variable (via linker flag) to look in the app

One additional thought is that since the VST/AU/AAX all need the same library, you end up including it several times which can make the installer quite large. So … probably better to copy relevant (larger) libraries as a post script in the installer, rather than have 4 copies in the installer?

Win:

• Install all DLLs to C:\Windows\system32

I don’t know that all DAWs search this directory … but it seems to be the case?

[moritzsur]

Saving you all the details and reasons, yes I went for system32 on windows, but I recompiled the library myself with a custom name to avoid any potential conflicts.
All executables will search this path if the library isn’t found in the executables path.

Can’t say anything about Mac since I was able to use a static version there…

[aaronleese1]

Yeah, I saw your post here:

Deploying an ONNX model

We took the dynamic library path back when we integrated onnxruntime in one of our EQs a few years ago. ORT builder did not exist back then and our attempts to build a static library version of the onnx runtime failed especially due to clashes with the static linked protobuf dependency all our plugins have which clashed with the protofbuf version integrated in onnx runtime, which was of course incompatible with the version we used… This was such a big pain that we didn’t revisit that topic again…

One of the libraries in question here is ONNX, in fact.

I’ve noticed that Windows already has a (minimal) install of onnxruntime in system32. It won’t work of course, and I can’t overwrite it, so I’m going to try and add a company specific prefix as suggested.

Given that on Windows you run a build.bat file to build onnx, I’m not sure how to go about this, but I’m sure the answer will present itself (eventually)

[edit] actually, there is a cmake file, and you just have to replace “onnxruntime” with “onnxruntime_company” in a couple dozen places.

The windows /DelayLoad (and then placing the library in AppData or some other custom path) looks like a nice option too if it works, and of course I’ll try to get a static build (though that has failed so far).

juce::DynamicLibrary is nice too. I’d never noticed that class before. A shame you can’t just pass an arbitrary path to it, but I understand why that might be a limitation. Guessing there is no easy way to make this one work for a custom path on windows.

[olilarkin]

I don’t think you should be putting stuff in windows/system32. Have you tried linking ONNX Runtime Statically e.g. using my ort-builder

[aaronleese1]

I have! Great work on that too!

I tried it first with your project, but got a message that onnx models were not supported.

After some googling I came to realize there are ORT models which are different than ONNX models (the ORT ones use a minimal build of onnx, the ONNX ones use a full build).

Correct me if I’m wrong, but it seemed like I could only run ORT models using your runtime?

ORT model format

[olilarkin]

You can read up about the arguments to the onnx runtime build.py, But yeah, I think if you remove -minimal then you can load .onnx

[aaronleese1]

I don’t see that file, is it in your repo or elsewhere? Happy to try and see what happens, I would love to have a static build of the full onnx lib. My understanding of this, however, is that it’s quite difficult because of the various dependencies (protobuf, etc).

In all honesty, it would be hard to justify including the static lib in distributable though, since that would mean having 4 copies of it, one each in VST3/AU/AAX/Standalone, and the full build is fairly large.

[olilarkin]

this is why i made ort-builder and why using .ort format with a slimmed static build might be a good idea

here are the ORT docs:

Custom build

here is where the ORT build.py gets called in ort-builder

olilarkin/ort-builder/blob/main/build-mac.sh#L11

[aaronleese1]

Ahh, I see. I had misunderstood a few things here.

First, I didn’t know you could build the CPP libraries with the python build command, awesome!

Also, I hadn’t noticed the convert_ONNX_to_ORT script!

I’m curious how that is even possible, since the full build can apparently do all sort of things the minimal build cannot. My understanding was that ORT was for minimal runtime, ONNX was for full.

I have projects that can only export to ONNX format, but if I can translate them and run on the ORT runtime, that would be great.

One question - any chance you have plans to update the onnxruntime repo? You are at 1.16, but latest is 1.18.

I’ll give this a try, thanks!

[olilarkin]

yes i’ll update it at some point

here is another project building static libs of ORT: Release v1.17.1 · supertone-inc/onnxruntime-build · GitHub

[asimilon]

@aaronleese1

rather than have 4 copies in the installer

This shouldn’t be a concern, compression will turn those 4 copies into essentially one + however many bytes it takes for it to say “make another 3 copies of this please”. Disk space after installation might be a concern if users are blindly installing all plugin types without needing to.

[aaronleese1]

Well, I thought it would as well … but tried it here and the installer went from ~300M to 890M.

Maybe there is a flag somewhere that I need to set. I’m using Whiteboxes Packages too (not packagebuilder). Both use the same packages framework of course.

[aaronleese1]

So you know, pipenv has trouble installing libonnxruntime.1.16 … says the min is 1.17 now.

This is in a newly created venv, and I ran pipfile --clear just to be sure. I guess this means pip (fully up to date) doesn’t find this older package?

 pipenv run pip install onnxruntime==1.16.3 
ERROR: Could not find a version that satisfies the requirement onnxruntime==1.16.3 (from versions: 1.17.0, 1.17.1)
ERROR: No matching distribution found for onnxruntime==1.16.3

[asimilon]

Oh, that’s interesting to know, and somewhat surprising.

[aaronleese1]

I’m in a venv, but I think it may have been trying to install to root there (in which case the system may be imposing the version requirement?).

Not my area, so just guessing

[olilarkin]

For the record: I now think statically linking ORT in plug-ins is probably a bad idea due to the risk of ODR violations or other clashes with DAWs that also link their own ORT. For macOS linking a dylib in the plug-in bundle is not so painful, still not sure what the best thing on Windows is. Putting your own ORT in window system32 seems nasty. I’ve updated the README.md on ort-builder accordingly.

[aaronleese1]

I’m still doing dynamic linking here (using the system32 and custom naming for the DLL on Win), though I would greatly prefer to use static.

Can you say more about the issues, and if you think/hope this might change in the near future?