3 ms·

When you statically compile an application, you only store text (code) of functions you actually use, generally, so unless you're using all 400Mb of code you're

When you statically compile an application, you only store text (code) of functions you actually use, generally, so unless you're using all 400Mb of code you're not going to have a 400Mb+ binary. I don't think I've ever seen a dependency that was 400Mb of compiled code if you stripped debug information and weren't embedding graphical assets, so I'm not sure how relevant this is in the first place. 400Mb of opcodes is... a lot.

vvanders 2y ago
Yes, this is lost in most discussions when it comes to DSOs. Not only do you have the complexity of versioning and vending but also you can't optimize with LTO and other techniques(which can make a significant difference in final binary size). If you've got 10-15+ consumers of a shared library or want to do plugins/hot-code reloading and have a solid versioning story by all means vend a DSO. If you don't however I would strongly recommend trying to keep all dependencies static and letting LTO/LTCG do its thing.
- intelVISA 2y ago
  Indeed, I'm biased but often the arguments in favor of shared objs have fundamental misconceptions that betray a lack of lower-level tinkering that makes it hard to take seriously.
  - saagarjha 2y ago
    The same can be said for any position in this debate.
AshamedCaptain 2y ago
I have seen a binary that is approximately 1.1GB of text. That is without debug symbols. With debug symbols it would hit GDB address space overflow bugs all the time. You have not seen what 30 year old engineering software houses can produce. And this is not the largest software by any chance. Also, sibling comments argue that kernel samepage merging can help avoid the bloat of static linking. But here what you argue will make every copy of the shared libraries oh-so-slightly-different and therefore prevent KSM from working at all. Really, no one is thinking this through very well. Even distributions that do static linking in all but name (such as NixOS) do still technically use dynamic linking for the disk space and memory savings.
- packetlost 2y ago
  Your poor I$. The fact of the matter is outside of GPU drivers and poorly designed GUI applications, that's an extreme statistical outlier.
  - lostmsu 2y ago
    You mean GPU libraries, right? Just watch how these become used in every other app over the next few years. And yes, the fact that you won't use those apps does not make it easier for the rest of us.
  - AshamedCaptain 2y ago
    Sum the GPU driver and the mandatory LLVM requirement that comes with it, and you already have almost half a gigabyte of text per exec. No wonder that your logic forces you to literally dismiss all GUI applications as "extreme statistical outliers" out of hand. For the record, the 1.1GB executable I'm thinking about is a popular _terminal-only_ simulation package. No GUI.
    - nightowl_games 2y ago
      Can't you just tell us what it is?
    - packetlost 2y ago
      Most applications do not use CUDA (I assume that's what you're referring to) and the ones that do only need to pull in the runtime (libcudart_static, in this case) which is nowhere near as big. You don't link all of LLVM into a CUDA application lol
      - AshamedCaptain 2y ago
        For the record any application using shader definitely needs "all of LLVM", and most Gtk+ applications are using shaders due to the ill-conceived notion that GPUs are faster at 2d acceleration. So yes, all GUI apps are linking in all of the graphics driver and all of LLVM.

vvanders 2y ago

Yes, this is lost in most discussions when it comes to DSOs. Not only do you have the complexity of versioning and vending but also you can't optimize with LTO and other techniques(which can make a significant difference in final binary size). If you've got 10-15+ consumers of a shared library or want to do plugins/hot-code reloading and have a solid versioning story by all means vend a DSO. If you don't however I would strongly recommend trying to keep all dependencies static and letting LTO/LTCG do its thing.

intelVISA 2y ago
Indeed, I'm biased but often the arguments in favor of shared objs have fundamental misconceptions that betray a lack of lower-level tinkering that makes it hard to take seriously.
- saagarjha 2y ago
  The same can be said for any position in this debate.

AshamedCaptain 2y ago

I have seen a binary that is approximately 1.1GB of text. That is without debug symbols. With debug symbols it would hit GDB address space overflow bugs all the time. You have not seen what 30 year old engineering software houses can produce. And this is not the largest software by any chance. Also, sibling comments argue that kernel samepage merging can help avoid the bloat of static linking. But here what you argue will make every copy of the shared libraries oh-so-slightly-different and therefore prevent KSM from working at all. Really, no one is thinking this through very well. Even distributions that do static linking in all but name (such as NixOS) do still technically use dynamic linking for the disk space and memory savings.

packetlost 2y ago
Your poor I$. The fact of the matter is outside of GPU drivers and poorly designed GUI applications, that's an extreme statistical outlier.
- lostmsu 2y ago
  You mean GPU libraries, right? Just watch how these become used in every other app over the next few years. And yes, the fact that you won't use those apps does not make it easier for the rest of us.
- AshamedCaptain 2y ago
  Sum the GPU driver and the mandatory LLVM requirement that comes with it, and you already have almost half a gigabyte of text per exec. No wonder that your logic forces you to literally dismiss all GUI applications as "extreme statistical outliers" out of hand. For the record, the 1.1GB executable I'm thinking about is a popular _terminal-only_ simulation package. No GUI.
  - nightowl_games 2y ago
    Can't you just tell us what it is?
  - packetlost 2y ago
    Most applications do not use CUDA (I assume that's what you're referring to) and the ones that do only need to pull in the runtime (libcudart_static, in this case) which is nowhere near as big. You don't link all of LLVM into a CUDA application lol
    - AshamedCaptain 2y ago
      For the record any application using shader definitely needs "all of LLVM", and most Gtk+ applications are using shaders due to the ill-conceived notion that GPUs are faster at 2d acceleration. So yes, all GUI apps are linking in all of the graphics driver and all of LLVM.