4 ms·

Slight offtopic: anyone else annoyed by the darwins crappy support for static linking and general extreme lack of documentation? E.g lack of -Bstatic option an

Slight offtopic: anyone else annoyed by the darwins crappy support for static linking and general extreme lack of documentation? E.g lack of -Bstatic option and similar?

saagarjha 6y ago
Apple generally prefers dynamic linking and thus carries over to what they offer to third parties.
- dilyevsky 6y ago
  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 6y ago
    How do you update OpenSSL if everything statically links it?
    - dilyevsky 6y ago
      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 6y ago
        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 6y ago
        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 6y ago
        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 6y ago
        Runtime loader won’t restart applications for you
    - jcelerier 6y ago
      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.
    - Wowfunhappy 6y ago
      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.
- Wowfunhappy 6y ago
  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!
  - saagarjha 6y ago
    Yeah, you largely lose the "you can update this library in all your apps at once" benefit unfortunately.
jcelerier 6y ago
the problem is that macos's kernel API isn't stable at all (like, even across minor macOS versions, and I have heard rumors that different mac hardware may get different kernels... though not sure about that one). So you can't statically link libc / libSystem unless you want your app to only work on one machine.
- dilyevsky 6y ago
  Yeah I’m actually fine with that part. Even application level libs are still mostly dynamically linked and you can’t for example take a .dylib and link it statically (not with standard tooling at least)
  - jcelerier 6y ago
    ... what do you mean then ? static linking your own dependencies does not require anything specific. I ship an app that statically links qt, ffmpeg, llvm, and a few other massive libs without issues.

Slight offtopic: anyone else annoyed by the darwins crappy support for static linking and general extreme lack of documentation? E.g lack of -Bstatic option and similar?

saagarjha 6y ago

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

dilyevsky 6y ago
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 6y ago
  How do you update OpenSSL if everything statically links it?
  - dilyevsky 6y ago
    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 6y ago
      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 6y ago
        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 6y ago
      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 6y ago
        Runtime loader won’t restart applications for you
  - jcelerier 6y ago
    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.
  - Wowfunhappy 6y ago
    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.
Wowfunhappy 6y ago
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!
- saagarjha 6y ago
  Yeah, you largely lose the "you can update this library in all your apps at once" benefit unfortunately.

jcelerier 6y ago

the problem is that macos's kernel API isn't stable at all (like, even across minor macOS versions, and I have heard rumors that different mac hardware may get different kernels... though not sure about that one). So you can't statically link libc / libSystem unless you want your app to only work on one machine.

dilyevsky 6y ago
Yeah I’m actually fine with that part. Even application level libs are still mostly dynamically linked and you can’t for example take a .dylib and link it statically (not with standard tooling at least)
- jcelerier 6y ago
  ... what do you mean then ? static linking your own dependencies does not require anything specific. I ship an app that statically links qt, ffmpeg, llvm, and a few other massive libs without issues.