None of the operating systems have a user facing packaging tool for libraries (so called DLL hell), so it is up to you to add libraries to the installers or supply an installation readme.
(I am aware of linux apt, yast, portage etc. we can have a debate about “user facing” )
You can also check dynamic linking vs. static linking, if the license allows it (L-GPL?) and I think the OS imposes some restrictions too (search for static runtime linking).
I was talking about the standalone version for now. The error message reads:
./Odin: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./Odin)
The build machine is on Ubuntu18.04 with some libraries installed without which JUCE wouldn’t compile when starting the project.
The target machine is a vanilla Ubuntu18.04 - at least in regards to JUCE
As for plugins inside hosts: I currently have no way of testing this.
Ok so that means I either have to provide install instructions, an install script or configure the whole thing to be installed by the many package managers available? I have no exposure to the last point unfortunately.
Regarding ldd: yeah that one just spits out a huge list of dependencies
Anyways: This was more of a “am I doing it wrong?” kinda question, if this is the reality of software deployment then I’ll have to take it that way. While we’re at it: Will I experience similar things on Win/Mac?
You may also have the option of static linking all your dependencies, which would bloat your executable a bit, but would make it more self-contained. I think most Linux systems ship with both static and dynamic versions of libm, but getting the projucer-generated makefile to select the static version is left as an exercise for the reader