On: Why Apple Chose Clang (2008)

[dilyevsky]

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...

[tsimionescu → dilyevsky]

How do you update OpenSSL if everything statically links it?

[jcelerier → tsimionescu]

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.

[dilyevsky → tsimionescu]

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

[tsimionescu → dilyevsky]

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.

[dilyevsky → tsimionescu]

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?

[yuushi → dilyevsky]

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...

[dilyevsky → yuushi]

Runtime loader won’t restart applications for you

[Wowfunhappy → tsimionescu]

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.