6 ms·

Not a macOS dev but maybe one can clarify: is the title "No more system shared libraries in macOS 11" actually true? The documentation reads to me as a restrict

by DCKing 6y ago

Not a macOS dev but maybe one can clarify: is the title "No more system shared libraries in macOS 11" actually true? The documentation reads to me as a restriction on how you read dynamic libraries (is using only dlopen controversial here? also just trying to understand), not on which system libraries are actually there. It seems dlopen with custom system dylibs would still work if there is also a means to get your dylibs in the system cache? Based on that piece of docs alone I see no reason to grab my pitchfork just yet. Anyway, I was expecting a few shitstorms to start happening over macOS 11. Apple not announcing any major deprecations (edit: or removals) for this transition - even OpenGL/CL is still there, depecrated - was suspicious.

akmarinov 6y ago
OpenGL was deprecated last year
- kalleboo 6y ago
  Everyone thought it was deprecated last year so that they didn't have to support it on ARM Macs, but it appears (not 100% confirmed until people actually get these things) like it is still there and working on ARM Macs (albeit deprecated)
  - pjmlp 6y ago
    It is officially documented as being available in ARM Macs.
    - kalleboo 6y ago
      Yeah but prerelease documentation has been wrong before.
      - oneplane 6y ago
        Isn't that why it's called "Pre" release? If there is a chance of changes between the release and what comes before that I'd say that makes sense. Say a 'release' turns out to have a discrepancy between documentation and reality, that's when the problems start to mount.
Someone 6y ago
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-beta-release-notes https://developer.apple.com/documentation/macos-release-note... has the text. dlopen will just work, but you can’t crawl through system directories anymore, hoping to find a shared library. It wouldn’t surprise me if there’s no way to get your dynamic library there anymore, as this explicitly says it’s of the system provided ones.
frogblast 6y ago
You're correct. For 3rd-party provided dylibs, it also isn't necessary to get them into the system cache. dlopen() will look for the dylib first (as today), and if the file doesn't exist, it'll look in the shared cache. So the only people this actually impacts are those who stat() system-provided dylibs before calling dlopen(). They should just skip the stat(), and go straight to calling dlopen(). Certainly not worthy of the end-of-the-world vibes in the twitter thread...
- DCKing 6y ago
  Thanks for the clarification. I'm guessing people are just looking for the inevitable pitchfork worthy big bad breaking change, but we haven't found one yet (although I'm slightly annoyed my Macbook will be out of official support with this release). @dang - I flagged this for the editorialized title, in my view it's worth updating this to something like "Restrictions on reading dynamic libraries in macOS 11".
- gspr 6y ago
  > They should just skip the stat(), and go straight to calling dlopen(). But `stat`ing it used to be fine on a Mac. And `stat`ing it is fine on other OSs. Why force software to change for no apparent reason just to appease the arbitrary whims of Apple? (And if it's not an arbitrary whim, you'd think they'd at least hint at the upsides of this, no?)
  - Someone 6y ago
    Even ignoring the race condition, has stating shared libraries ever been documented as a method to ascertain existence of a shared library? My guess as to the reason: I would guess the new way is faster, more secure, or takes less memory. Leaving an unused copy of binaries around would be wasting disk space (and yes, disks are enormous nowadays, but SSDs aren’t) It may cache data from Apple’s servers, but calling it a cache sounds incorrect, though.
    - barrkel 6y ago
      I wouldn't think it's any of those reasons. I'd rather think it's to transparently serve up different libraries based on the caller, even if the name is the same, in the name of compatibility or something like it.

by DCKing 6y ago

akmarinov 6y ago

OpenGL was deprecated last year

kalleboo 6y ago
Everyone thought it was deprecated last year so that they didn't have to support it on ARM Macs, but it appears (not 100% confirmed until people actually get these things) like it is still there and working on ARM Macs (albeit deprecated)
- pjmlp 6y ago
  It is officially documented as being available in ARM Macs.
  - kalleboo 6y ago
    Yeah but prerelease documentation has been wrong before.
    - oneplane 6y ago
      Isn't that why it's called "Pre" release? If there is a chance of changes between the release and what comes before that I'd say that makes sense. Say a 'release' turns out to have a discrepancy between documentation and reality, that's when the problems start to mount.

Someone 6y ago

https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-beta-release-notes https://developer.apple.com/documentation/macos-release-note... has the text. dlopen will just work, but you can’t crawl through system directories anymore, hoping to find a shared library. It wouldn’t surprise me if there’s no way to get your dynamic library there anymore, as this explicitly says it’s of the system provided ones.

frogblast 6y ago

You're correct. For 3rd-party provided dylibs, it also isn't necessary to get them into the system cache. dlopen() will look for the dylib first (as today), and if the file doesn't exist, it'll look in the shared cache. So the only people this actually impacts are those who stat() system-provided dylibs before calling dlopen(). They should just skip the stat(), and go straight to calling dlopen(). Certainly not worthy of the end-of-the-world vibes in the twitter thread...

DCKing 6y ago
Thanks for the clarification. I'm guessing people are just looking for the inevitable pitchfork worthy big bad breaking change, but we haven't found one yet (although I'm slightly annoyed my Macbook will be out of official support with this release). @dang - I flagged this for the editorialized title, in my view it's worth updating this to something like "Restrictions on reading dynamic libraries in macOS 11".
gspr 6y ago
> They should just skip the stat(), and go straight to calling dlopen(). But `stat`ing it used to be fine on a Mac. And `stat`ing it is fine on other OSs. Why force software to change for no apparent reason just to appease the arbitrary whims of Apple? (And if it's not an arbitrary whim, you'd think they'd at least hint at the upsides of this, no?)
- Someone 6y ago
  Even ignoring the race condition, has stating shared libraries ever been documented as a method to ascertain existence of a shared library? My guess as to the reason: I would guess the new way is faster, more secure, or takes less memory. Leaving an unused copy of binaries around would be wasting disk space (and yes, disks are enormous nowadays, but SSDs aren’t) It may cache data from Apple’s servers, but calling it a cache sounds incorrect, though.
  - barrkel 6y ago
    I wouldn't think it's any of those reasons. I'd rather think it's to transparently serve up different libraries based on the caller, even if the name is the same, in the name of compatibility or something like it.