181–190 of 249 posts
Earlier quoted context omitted.
> I believe that this the reason why static libraries are usually shipped as separate object files (.o) within ar archives (.a), as those were only linked in on demand. Yep. One function per C/obj file for smallest static binary possible.
Can't you achieve the same result with -ffunction-sections?
As a side note, you are almost always better off (also on this case) by plotting power laws on a log scale.
The upgrade problem has almost nothing to do with download size. The real problem is that you have > 100 binaries which depend on those libraries, and instead of having the library authors go and update the library, you need each team responsible for one or more binaries to go and take the new library and release a new version of their binary.
And then, when you want to check if your system is safe from Heartbleed, instead of checking if you have libopenssl > 1.0.1g, you need to check if bin1 > 1.2.56 or > 0.6.89h, bin2 > 5.76.1, or > 4.6.215,... bin100 > 1.67.89.
And of course, if one of them does NOT have a newer version compiled with the patched library, you need to fix it yourself, and maintain a patched version of the binary. Assuming that you even know that binary had been linked to the vulnerable library.
Earlier quoted context omitted.
> There is a good reason to page- or superpage-align code generally; it burns some virtual memory but reduces TLB overhead and therefore misses / invalidations, which are very costly. You would want to do the same with executable code in a static-linked binary. But most code isn't performance critical. Thus trying to align functions to page boundaries is just wasting memory. Even in performance critical code, alignin…
> But most code isn't performance critical. Wasting TLB slots on your unimportant code still pessimizes your hot code. > Thus trying to align functions to page boundaries is just wasting memory. No one aligns individual functions to page boundaries; you align the entire loadable code segment to a page (or preferably, superpage) boundary. > Even in performance critical code, aligning to cache line sizes is enough and…
> The total download cost to upgrade all binaries on my system which were affected by CVEs in 2019 is 3.8 GiB. This is reduced to 1.0 GiB if you eliminate glibc. The upgrade problem has almost nothing to do with download size. The real problem is that you have > 100 binaries which depend on those libraries, and instead of having the library authors go and update the library, you need each team responsible for one or…
This is a solvable problem. Package managers such as Nix and Guix rebuild packages if any of their transitive dependencies have been changed.
The difficult part are now language-specific ecosystems that use lock files to lock all their dependencies. Traditional C/C++ programs, either statically linked or dynamically linked, have a dependency graph such that e.g. each program that uses OpenSSL has the same package definition in their transitive dependencies. However, e.g. Rust programs may have different versions of the same crate locked.
(There are solutions to that, but there is still work to be done.)
Earlier quoted context omitted.
> I believe that this the reason why static libraries are usually shipped as separate object files (.o) within ar archives (.a), as those were only linked in on demand. Yep. One function per C/obj file for smallest static binary possible.
Can't you achieve the same result with -ffunction-sections?
> The total download cost to upgrade all binaries on my system which were affected by CVEs in 2019 is 3.8 GiB. This is reduced to 1.0 GiB if you eliminate glibc. The upgrade problem has almost nothing to do with download size. The real problem is that you have > 100 binaries which depend on those libraries, and instead of having the library authors go and update the library, you need each team responsible for one or…
The real problem is that you have > 100 binaries which depend on those libraries, and instead of having the library authors go and update the library, you need each team responsible for one or more binaries to go and take the new library and release a new version of their binary. This is a solvable problem. Package managers such as Nix and Guix rebuild packages if any of their transitive dependencies have been change…
Earlier quoted context omitted.
> [...] Having said that, I do wish the average linux distro still statically linked everything in /bin and /sbin. It was nice to still be able to administrate the system even when the dynamic libraries were hosed. [...] This argument came up back when Solaris 10 was in development and the project to get rid of static link archives for system libraries came up (search for Solaris "unified process model"). The disposi…
Sometimes solutions give rise to new categories of issues, and it's difficult to connect the dots to the root cause. If you believe dynamic linking hasn't introduced an even broader array of difficulties for C coders needing to support both, then please read Ulrich Drepper's DSO tutorial which gives a pretty good rundown: https://software.intel.com/sites/default/files/m/a/1/e/dsoho... If I remember correctly, it was…
Earlier quoted context omitted.
But we haven't learned from this as modern, non-make based build systems still suffer from terribly slow compiles. Take Rust for example. I don't know a single project that uses make to build (they all use cargo), yet Rust suffers from extremely slow compile times. Much of this (as far as I understand) comes from the LLVM compiler, which is why I was picking on compilers.
Rust's slow builds come from rustc, which is based on LLVM. Other LLVM frontends, like clang, are not as slow. This is in part because borrow-checking has a cost.
Earlier quoted context omitted.
Are these also issues for languages like Go and Rust?
No, not for Rust, and not for Goland, IIRC. The reason is that they have proper namespacing functionality in the language, and generally modern languages record dependency metadata in the direct dependents. This is strictly a C problem.