[bigyabai]

If developers have to static-link all their libraries to ship a Mac-native app, you're already doing most of the work to ship a cross-platform web runtime like Electron.

Therefore it's not super surprising that successful products like Discord/Slack/Spotify gave up on a good native experience decades ago.

[dagmx]

Why do you believe you need to static link to ship a Mac native app?

There’s no such requirement. Tons of Mac apps bundle dylibs within them.

[kccqzy]

The article clearly states that Apple provides standardized locations for apps to store their dynamically linked libraries.

[ux266478]

one of the weirdest and most off-putting parts of macos for me was that dyld isn't aware of that standardized location. a lot of curious oversights the more you pick at it.

[dagmx]

What do you mean? I can just tell the linker to link against something in the shared cache and it finds it. It’s been as simple as `-framework <FrameworkName>`

I’ve never had to do extra work to find a system vendored dylib in my decades of supporting cross platform apps.

[eschaton]

They probably mean that they don’t like the way the “install name” (as it’s referred to) of a shared library is embedded in the library and then copied to whatever links the library, and is then used to find the library at runtime. I suspect they’d prefer to build the shared library with an arbitrary install name and then just have it found automatically by being in the Frameworks or Libraries directory.

Most platforms don’t have a concept of “install name” distinct from the library name; the value was originally the full path to the deployment location of the library, which was revised to support meta-paths (like `@rpath/LibraryName`) in Mac OS X 10.4 and 10.5 and is what the runtime dynamic loader (dyld) uses to match a library at load time. So an application’s executable can have a set of self-relative run path search paths, which is how it can load libraries from its Frameworks and Libraries directories.

[dagmx]

Ah fair enough. But generally an rpath is pretty good to go out of the box.

The primary binary encodes relative to the executable path and any dylib that loads from it should be able to (by default) load relative to that

[eschaton]

Depends on whether you’re building with Xcode; when I worked on it, I ensured that the templates included with Xcode would have the right setup to declare appropriate run path search paths for applications, and appropriate install names for frameworks and (shared) libraries.

However when building with just command line tools and not passing all the same arguments an Xcode project and target causes to be passed, you have to do extra work to ensure the right run path search paths get into built executables and the right install names get into built libraries and frameworks.

That latter is to ensure that if you don’t pass those extra arguments, executables and shared libraries are built for Darwin-based platforms as much as reasonably possible like they are on other UNIX-like platforms.

[ux266478]

I mean I had to manually patch the rpaths of macos binaries distributed as an app bundle, because dyld didn't have the relative location of the shared libs in the app bundle in its search path. Not a huge deal, since patching rpaths was also part of the other Unix pipelines, the reasoning was just different. Patching rpaths on other platforms was because we were distributing dependencies in the base directory of the application, which isn't the standard way to do things. On mac, it was because the dynamic linker wasn't aware of app bundle structure for some reason, which is a weird disconnect between an OS standard and a basic system component.

[ux266478]

statically linking dependencies is a trivial change in a build script. why are you acting like its some esoteric forbidden art?