2 ms·

Firefox is (optionally) still distributed as a "distroless" thing called a tarball. Ardour (my project) is (also) distributed in this way. You get a directory

Firefox is (optionally) still distributed as a "distroless" thing called a tarball. Ardour (my project) is (also) distributed in this way. You get a directory tree that contains the executable, all required dynamically-linked libraries and a bunch of non-code files. The actual program itself is a tiny shell-script that sets LD_LIBRARY_PATH to point into the app directory tree. The result runs on any Linux distro that can provide libstdc++ and Xlib. Except, ironically, Nixos (because they screw with LD_LIBRARY_PATH use). Another way of doing this that has been around on Unix for decades is to use the linker's rpath argument, but on many Unix systems for a long time, the runtime linker could not handle relative rpaths, and so this mechanism fell into relative disuse. And of course, macOS has been doing something very similar with its "app" packaging, which relies on launchd to set DYLIB_LIBRARY_PATH (their equivalent to LD_LIBRARY_PATH) to include the app tree itself. The result is largely independent of the version of macOS the install occurs on, although that is dependent on some additional behind the scenes magic with the macOS run time linker.

soraminazuki 3y ago
LD_LIBRARY_PATH should work as expected on NixOS. If I may guess, the problem is that you don't have libc / libstdc++ / Xlib included in your LD_LIBRARY_PATH.
- PaulDavisThe1st 3y ago
  I no longer recall the precise reason. I gave up caring when it became clear that of all the myriad Linux distributions, Nixos is the only one that prevents this model from working in precisely the way it works on every other distro.
comex 3y ago
FYI, that's not how macOS app bundles work. While ELF binaries typically list the shared libraries they depend on with just a filename, Mach-O binaries use a path. This can be an absolute path, which is typically used for OS-provided libraries. Or it can be a path relative to the binary containing the dependency, which is typically used for libraries contained in app bundles. (See the bottom of `man 1 dyld` for more info.) Thus there's no need to set environment variables just to run an app, and launchd doesn't do so. There is a variable called DYLD_LIBRARY_PATH, but it mostly exists for development/testing purposes. The way it works is that before the dynamic linker resolves a dependency path from a binary, it first searches DYLD_LIBRARY_PATH for a file matching the basename of the path, ignoring the rest of the path. Any such file will take precedence over the original path. I have seen some apps that rely on a wrapper shell script that sets DYLD_LIBRARY_PATH. I'm not sure if they just have the wrong dependency paths, or if they're dealing with other special cases like calls to dlopen with a bare filename.
- PaulDavisThe1st 3y ago
  You are absolutely right and I was talking out of my rear end. I know you are right because setting the path in the ELF is a major step in building the Ardour macOS packages. That said, I still have this vague memory that launchd does in fact reset some linker-related vars before exec-ing the app binary. Could be wrong about that too.

soraminazuki 3y ago

LD_LIBRARY_PATH should work as expected on NixOS. If I may guess, the problem is that you don't have libc / libstdc++ / Xlib included in your LD_LIBRARY_PATH.

PaulDavisThe1st 3y ago
I no longer recall the precise reason. I gave up caring when it became clear that of all the myriad Linux distributions, Nixos is the only one that prevents this model from working in precisely the way it works on every other distro.

comex 3y ago

FYI, that's not how macOS app bundles work. While ELF binaries typically list the shared libraries they depend on with just a filename, Mach-O binaries use a path. This can be an absolute path, which is typically used for OS-provided libraries. Or it can be a path relative to the binary containing the dependency, which is typically used for libraries contained in app bundles. (See the bottom of `man 1 dyld` for more info.) Thus there's no need to set environment variables just to run an app, and launchd doesn't do so. There is a variable called DYLD_LIBRARY_PATH, but it mostly exists for development/testing purposes. The way it works is that before the dynamic linker resolves a dependency path from a binary, it first searches DYLD_LIBRARY_PATH for a file matching the basename of the path, ignoring the rest of the path. Any such file will take precedence over the original path. I have seen some apps that rely on a wrapper shell script that sets DYLD_LIBRARY_PATH. I'm not sure if they just have the wrong dependency paths, or if they're dealing with other special cases like calls to dlopen with a bare filename.

PaulDavisThe1st 3y ago
You are absolutely right and I was talking out of my rear end. I know you are right because setting the path in the ELF is a major step in building the Ardour macOS packages. That said, I still have this vague memory that launchd does in fact reset some linker-related vars before exec-ing the app binary. Could be wrong about that too.