Hacker News Reader

Comment by saagarjha | Hacker News Reader

Apple generally prefers dynamic linking and thus carries over to what they offer to third parties.

Although it should perhaps be noted, they aren't packaged as they are in Linux, right? Apps generally ship their own copies of libraries inside of the app bundle, and it's perfectly common to have multiple copies of a library as a result. I'm sure I have at least ten versions of the Sparkle framework for instance!

This conveniently avoids most of the downsides of dynamic linking, except I don't think you get any of the upsides, either—which is to say I'm not sure what the point is. I kind of like it because, since I don't mind breaking code signatures, I can replace the frameworks in third party apps with updated copies. But I'm pretty sure that's not Apple's intended use!

Yeah, you largely lose the "you can update this library in all your apps at once" benefit unfortunately.

Yeah i just hate dynamic linking and wish we’d moved past this already. Makes everything more complex for no real gain as far as i can tell...

How do you update OpenSSL if everything statically links it?

You still have to reload everything that dynamically linked it wont you? Also that case only applies if you didn’t make any api changes

You can reboot the system to take care of the reload. That's vastly simpler than updating all dependent programs, especially since updating dependent programs would likely come with other changes that you may not be ready for.

And yes, this is mostly useful for taking bug fixes, which most mature libraries release without API changes.

I disagree about “vastly simpler”. Only when you disregard all the complexity that managing shared libraries bring. Presumably all dependent packages will ship their own updates at some point and will be rebuilt anyway. And yes in a very specific case of having to emergency ship critical fix shared library is slightly advantageous but at what cost?

If by "reload" you mean "drop in an updated shared library and let the runtime loader do its job", I suppose so.

Yes, it only applies if you don't make any API (and ABI) changes, but that's what major, minor, patch versioning is for, and stable projects can go a long way on minor and patch versions...

Runtime loader won’t restart applications for you

this is only relevant on linux. on windows I just ran

     find . -iname '*ssl*.dll'

and I have something like 250 different results.

even if I just look for ssleay32.dll I have a ton of results:

    ./Program Files/Calibre2/app/DLLs/ssleay32.dll
    ./Program Files/darktable/bin/SSLEAY32.dll
    ./Program Files/Genshin Impact/ssleay32.dll
    ./Program Files/Genshin Impact/updateProgram/ssleay32.dll
    ./Program Files/LibreOffice/program/ssleay32.dll
    ./Program Files (x86)/Clementine/ssleay32.dll
    ./Program Files (x86)/Kodi/ssleay32.dll
    ./Program Files (x86)/GOG Galaxy/ssleay32.dll
    ./Program Files (x86)/iLok License Manager/ssleay32.dll
    ./Program Files (x86)/Seafile/bin/SSLEAY32.DLL
    ./ProgramData/GOG.com/Galaxy/prefetch/desktop-galaxy-updater/ssleay32.dll
    ./ProgramData/GOG.com/Galaxy/redists/ssleay32.dll
    ./ProgramData/GOG.com/Galaxy/temp/desktop-galaxy-updater/ssleay32.dll
    ./ProgramData/Intel/Installer/rs_sdk_2014/cache/4f6dfe1e-80c5-11e6-b7da-2c44fd873b55/plugins/ssleay32.dll
    ./ue4/UE_4.25/Engine/Binaries/ThirdParty/GoogleInstantPreview/x64/Release/ssleay32.dll
    ./ue4/UE_4.25/Engine/Binaries/ThirdParty/OpenSSL/Win64/VS2015/ssleay32.dll
    ./ue4/UE_4.25/Engine/Binaries/ThirdParty/svn/Win64/ssleay32.dll
    ./Users/blah/AppData/Local/GitHubDesktop/app-0.6.2/resources/app/git/mingw64/bin/ssleay32.dll
    ./Users/blah/AppData/Local/MEGAsync/ssleay32.dll
    ./Users/blah/AppData/Local/Microsoft/OneDrive/20.201.1005.0009/ssleay32.dll
    ./Users/blah/Desktop/Shotcut/ssleay32.dll
    ./Users/blah/Desktop/smplayer-portable-19.1.0.0/ssleay32.dll
    ./Users/blah/Documents/PacketSenderPortable/ssleay32.dll

so, "yay", dynamic linking is used. what does this gain ? exactly NOTHING.

The individual app developers have to update their apps to use newer OpenSSL. I don't see this as a problem because the app's developers generally need to test their software with updated OpenSSL anyway, in order to make sure everything still works.

Reply on news.ycombinator.com