when I want to install those to /opt/something only thing I need to do is install_name_tool -add_rpath /opt/something
This will add search directories to binary itself. There are some DYLD_* environment variables too but I'm not sure about them... (Some are SIP protected by the way)
PS: It may invalidate signed binaries. Again, not tested such use cases.
A library itself decides if it is relocatable or fixed. If it is fixed the MH_DYLIB records its install name as /path/to/binary (generally by setting DYLIB_INSTALL_NAME_BASE so xcodebuild will merge that with the library name automatically). The binary must be at that path. However this can (and often is) a symlink just like other systems use where /usr/lib/somelib.dylib -> /usr/lib/somelib.1.3.dylib so that minor version updates can be made without rebuilding programs.
If a library wants to be relocatable it specifies an install name of @rpath/binary.
At runtime dyld creates a "run path list". Every time it encounters a load command with an @rpath name it tries substituting paths from the run path list until it finds the library. The main binary along with any dependencies can add entries to the run path list. These can be absolute paths or relative paths anchored from @executable_path or @loader_path. The former being the main binary and the latter being the path to the binary itself (eg if the main app loads a plugin the plugin can reference dependencies relative to the main app or itself as needed).
You can push your own paths in the mix with DYLD_LIBRARY_PATH (searched first) or DYLD_FALLBACK_LIBRARY_PATH (searched last). Check "man dyld" and "man ld" if you want more details.
None of the above requires modifying binaries and so doesn't invalidate code signatures. If you want to use install_name_tool on binaries you build pass "-headerpad_max_install_names" to ld so it will pad out the load commands which makes it easier to edit them.
There have been a bunch of security vulnerabilities around the Windows strategy of auto-loading any dependency from the same directory as the binary so YMMV.
> You can try to do this with rpath of $ORIGIN. But then you'll probably still run into libc issues -.-
Linux (g)libc is sort of equivalent to the Win32 API on Windows so you are not expected to ship your own version just like you don't ship your own ntdll, user32, etc. Since glibc has good backwards compatibility the onlye libc issue you will run into is having to compile against the oldest version you want to support.
And the irony? It was someone on Unix who came up with the idea that when foo.c contains #include "bar.h", the same directory where foo.c resides will be searched for that header first, by default, before other places.
The idea of doing that for the DLL search in Windows could have been inspired by C.
So you are saying this is why Windows users universally complain about "DLL Hell", and Linux users don't? Or is this how MS finally fixed Windows DLL Hell? (Presuming Windows DLL Hell is, indeed, fixed; I wouldn't know.)
DLL hell is about program installers depositing some common libraries, like the MSVC redistributable run-time, into the system folder. So then every other application is using the most recently clobbered version of it instead of the one it came with.
GNU/Linux doesn't have DLL hell only to the extent that there is an entire binary distro with maintainers beavering to keep all of the dependencies straight so that every program that needs a certain shared library is maintained to need the same version of it as any other program.
You will experience shared library hell as soon as you have your own binary application that is not in the upstream distro, and it happens to depend on one of the lesser libraries that do not do symbol versioning like openssl, libbz2 and whatnot.
I've dealt with this plenty in more than one Linux embedded dayjob. In one case, I hacked an elaborate library searching system around dlopen() into such a program.
That's a minimal issue for games. You ship all dependencies with a start script that points LD_LIBRARY_PATH where you want and everything's fine. Or maybe even ship a flatpak. Issues for games come from other places.
If your program is a binary executable, and you have to script around its startup, that is ugly and unprofessional; it looks very bad for the underlying OS and its basic userland infrastructure that you have to do anything like that.
Sure, but it's the standard way to use install_name_tool on macOS to do precisely what you described. The original commenter apparently is not aware of this.
basically you build your binary and set a rpath, let's say it is /usr/local/lib in your machine
mach-o binary stores: @rpath = /usr/local/lib libxyz = @rpath/libxyz.dylib.1
when I want to install those to /opt/something only thing I need to do is install_name_tool -add_rpath /opt/something
This will add search directories to binary itself. There are some DYLD_* environment variables too but I'm not sure about them... (Some are SIP protected by the way)
PS: It may invalidate signed binaries. Again, not tested such use cases.