19 ms·

As Linus points out, the utility of shared libraries depends on the situation. Widely used libraries like libxcb, libGL, and zlib that tend to have reasonably s

• brundolf 5y ago
  It seems to me that several circumstances have changed since the idea of dynamic linking first came about: - A whole lot of software is now open and freely available - The code-changes-to-binary-updates pipeline has been greased by a couple orders of magnitude, from internet availability to CI to user expectations around automatic updates (for both commercial and non-commercial software) - Disk space, and arguably even RAM, have become very cheap by comparison Given these, it seems worthwhile to re-evaluate the tradeoffs that come with dynamic linking
  • drewcoo 5y ago
    To underscore the gp's point, I have had to work with a 3rd party-provided .so before. No sources. A binary. And strict (if unenforceable) rules about what we could do with the binary.
    • CyberDildonics 5y ago
      I don't think that was their point at all. They were saying that dynamic linking creates flexibility and modularity that doesn't exist otherwise.
      • TeMPOraL 5y ago
        I think this was precisely the point. Shared libraries create seams you can exploit if you need to modify behavior of a program without rebuilding it - which is very useful if you don't want to or can't rebuild the program, for example because it's proprietary third-party software.
    • mikepurvis 5y ago
      I dealt with a situation like this for a ROS driver for a camera, where the proprietary SO was redistributable, but the headers and the rest of the vendor's "SDK" was not. The vendor clarified for me repeatedly that it would not be acceptable for us to re-host the SDK, that it was only accessible from behind a login portal on their own site. The solution we eventually came to was downloading the SDK on each build, using credentials baked into the downloader script: https://github.com/ros-drivers/pointgrey_camera_driver/blob/ae67188a5b49b56b1d5d5b102301f7d8a3523a92/pointgrey_camera_driver/cmake/download_flycap#L37 https://github.com/ros-drivers/pointgrey_camera_driver/blob/... The vendor was fine with this approach, and it didn't violate their TOU, though it sure did cause a bunch of pain for the maintainers of the public ROS CI infrastructure, as there were various random failures which would pop up as a consequence of this approach. I think eventually the vendor must have relented, as the current version of the package actually does still download at build time, but at least it downloads from a local location— though if that is permissable, I don't know why the headers themselves aren't just included in the git repo.
      • DaiPlusPlus 5y ago
        Have things changed at all since Pointgrey were acquired by FLIR?
        • 5y ago
  • atweiden 5y ago
    > Given these, it seems worthwhile to re-evaluate the tradeoffs that come with dynamic linking Perhaps this is just a Linux distro thing, but as someone who closely monitors the Void packages repo, dynamic linking burdens distro maintainers with hundreds of additional packages which need to be individually tracked, tested and updated. (Packages which could otherwise be vendored by upstream and statically linked during the build.) Dynamic linking also adds complexity to distro upgrades, because dependant packages often need to be rebuilt when the libraries they dynamically link to are changed or upgraded. For example, Void’s recent switch from LibreSSL to OpenSSL borked my install script which wasn’t aware of the change. It resulted in a built system whose XBPS package manager couldn’t verify SSL certs. On Arch, AUR packages were notoriously prone to dynamic linking errors (back when I still used it). Personally, I don’t find the bandwidth efficiency and CVE arguments for dynamic linking to be all that convincing [1]: Will security vulnerabilities in libraries that have been statically linked cause large or unmanagable updates? Findings: not really Not including libc, the only libraries which had "critical" or "high" severity vulnerabilities in 2019 which affected over 100 binaries on my system were dbus, gnutls, cairo, libssh2, and curl. 265 binaries were affected by the rest. 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. It is also unknown if any of these vulnerabilities would have been introduced after the last build date for a given statically linked binary; if so that binary would not need to be updated. Many vulnerabilities are also limited to a specific code path or use-case, and binaries which do not invoke that code path in their dependencies will not be affected. A process to ascertain this information in the wake of a vulnerability could be automated. [1]: https://drewdevault.com/dynlib https://drewdevault.com/dynlib
    • rkeene2 5y ago
      As someone who runs a Linux distribution, please don't vendor your dependencies for the benefit of distribution maintainers, it makes it much more difficult to build a coherent system. Running different versions of common libraries causes real annoyances.
      • 5y ago
  • vonwoodson 5y ago
    Isn’t this especially true in the world of containerization? We literally ship entire images or configurations of OS’s to run a single application or system function. Although, I have mixed feeling about containers, because I fully appreciate that Unix is the application and the software that runs on it are just the calculations. In that world, sure, a shared library makes sense the same way a standard library makes sense for a programming language. Thus, a container is “just” a packaged application. Regardless, this concept is so out of the realm of “performance” that it’s worth noting that the idea of trying to reduce memory use or hard disk space is not a valid argument for shared libraries.
    • FartyMcFarter 5y ago
      Google's distroless containers attempt to fix this issue: https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless
  • gautamdivgi 5y ago
    One tradeoff is security. If you're patching vulnerabilities, then just a single .so needs to be patched. With static linking every binary needs to be investigated and patched.
    • nickez 5y ago
      You can also argue that it is impossible to update dynamic libraries because they are used by multiple applications and you can't afford that any application breaks. So instead of being able to patch that one application where the security is needed, you now have to patch all of them.
      • gspr 5y ago
        > You can also argue that it is impossible to update dynamic libraries because they are used by multiple applications and you can't afford that any application breaks. That's where maintenance branches comes in. You fix only the security issue, and push out a new version.
  • alerighi 5y ago
    Also compilers nowadays are smarter and can perform link time optimizations. Meaning that if of a library you only use a single function, in the final executable you would only get that single function. In reality code that use static linking could be more efficient than code that uses dynamic linking. And you have to consider some performance penalty when using shared libraries. First you have a time penalty when loading the executable, since first you have to run the interpreter (ld-linux) and then your actual code. But also for each function call you have to make an indirect jump into it.
    • bonzini 5y ago
      > But also for each function call you have to make an indirect jump into it. Only the first call has a penalty. Then you call into the PLT and the PLT contains a direct jump to the function.
      • kaba0 5y ago
        It still has a cost over potential inlining (that allows for more optimizations as well). Of course if it is not a hotspot, it is meaningless.
      • creamytaco 5y ago
        The call into the PLT is a penalty.
        • bonzini 5y ago
          Sure but it's not an indirect jump.
  • drran 5y ago
    > Disk space, and arguably even RAM, have become very cheap by comparison CPU frequency and CPU cache are remaining small, so smaller binaries, which fit the cache, are running faster, and use less energy, and wastes less resources overall. > Given these, it seems worthwhile to re-evaluate the tradeoffs that come with dynamic linking Create your own distribution and show us benefits of static linking.
• herodoturtle 5y ago
  > that tend to have reasonably stable ABIs Today I learned about Application Binary Interfaces. (and thanks for the generally insightful comment)
• innagadadavida 5y ago
  Another important consideration is security. If there is an exploit in the library code and the original program authors do not release updates regularly, then it is really important to be able to patch the security issue.
• amelius 5y ago
  Perhaps then the OS should figure out which parts of an executable are common, so we can still have shared libraries except they are smarter and not visible to the user.
  • TeMPOraL 5y ago
    Except "being visible to the user" is a useful thing to have, as GP explained :). Or put in a different way: the problem is the "shared" part, not the "dynamic linking" part. Instead of static linking, you can avoid the issue of library versions by just shipping your shared libraries along with your program[0] - and this way, users still retain the ability to swap out components if the need arises. -- [0] - Well, you could, if you could rely on LD_LIBRARY_PATH to be set to "." by default. Windows is doing it right, IMO, by prioritizing program location over system folders when searching for DLLs to load.
    • higerordermap 5y ago
      > Well, you could, if you could rely on LD_LIBRARY_PATH to be set to "." by default. It's actually supported without LD_LIBRARY_PATH hacks, using DT_RPATH. You can do that by passing -rpath '$ORIGIN' to linker IIRC.
      • TeMPOraL 5y ago
        Thanks! I forgot all about it, in particular about '$ORIGIN' thing! Yes, I'm happy to see the person building the executable has at least some control over this. It's actually relevant to a project I'm working on (proprietary, Windows/Linux, uses shared libraries for both mandatory components and optional plugins) - I'm gonna check if and how we're setting RPATH for the Linux builds, it might need some tweaking.
  • simias 5y ago
    It's definitely technically doable: you'd have to checksum every read-only page of a program and see if you already have one in cache. But is it worth it though? Even "big" statically linked Rust programs are a few dozen MBs of executable (and not all of that is read-only, and even less will be shared with any other executable at any given time). With things like LTO identical source files can result in different machine code as well. In the end it would be a lot of trouble for potentially very little gains. At first I was annoyed that Rust defaulted to dynamic linking, it felt inefficient and overkill. But the more I think about it the less I can really justify doing it any other way, there are very few benefits to dynamic linking these days. The only one I can think of is overriding an application's behaviour through LD_PRELOAD, but few people know how to do that these days.
• choeger 5y ago
  You are right on track here. The complexity is real, but so are the benefits of a modular executable vs. a huge monolith. I fully understand why languages like rust demand static linking (their compilation model doesn't allow dynamic linking). But once you encounter a C-API boundary, you can as well make that a dynamic C-ABI boundary.
  • mrec 5y ago
    It's not the default, but Rust absolutely allows dynamic linking [1]. For example, Bevy encourages building the engine as a dynamic library during development to improve iteration turnaround times for the app code [2]. [1] https://doc.rust-lang.org/reference/linkage.html https://doc.rust-lang.org/reference/linkage.html [2] https://github.com/bevyengine/bevy/issues/791 https://github.com/bevyengine/bevy/issues/791
    • choeger 5y ago
      If I am not completely mistaken, if you produce a dynamic library with rust, you are limited to the C-ABI. For instance, you cannot import a polymorphic function from a dynamic library.
      • mrec 5y ago
        I haven't used it, but I don't believe that's the case. I think what you're describing is `#[crate_type = "cdylib"]` ("used when compiling a dynamic library to be loaded from another language"), whereas `#[crate_type = "dylib"]` produces a "dynamic Rust library".
      • iudqnolq 5y ago
        The rust abi isn't stable between compiler versions, but it does exist. Bevy can get away with using it because it's just to speed things up in development. Polymorphism is a separate issue. One way to do polymorphism in rust is monomorphism, where your polymorphic function is compiled to a specific version with no generics per caller. If you don't know the callers ahead of time this can't work. Another way is dynamic dispatch, where you have one polymorphic function that chooses what code to run per type at runtime. This can work with dynamic linking
• bch 5y ago
  > The important benefit is dynamic linking. The ability to change which library is being used without needing to rebuild the main program is really important. Or just having the option of loading the library at all. If you don’t need the functionality offered by libxyz, you’re not required to use it. One then has no end of language extensions that can be loaded into a generic interpreter to fit a script to whatever job they have at hand. Edit: Linus touched on this as a last point: > Or, for those very rare programs that end up dynamically loading rare modules at run-time - not at startup - because that's their extension model. My question: is it actually rare?
  • mypalmike 5y ago
    It is rare compared to the usual pulling in of required dependencies during build.
  • estebank 5y ago
    Most applications don't have runtime extensions. The few that do, really need them in order to be useful. I'm convinced that there's a Pareto Distribution where 20% of libraries really benefit from being dynamically loaded, where the remaining 80% is better served by static linking. Given that, it seems to me that dynamic linking should be both opt-in and properly supported, but the one that decides that should be the library maintainer.
• derefr 5y ago
  > If the program is statically linked, then nothing can happen Static libs are embedded into most object-file formats (e.g. ELF) as isolated compilation units. Could you not just replace the static library within the object-file at the linkage level, in about the same way that old "resource editors" could replace individual resources within object-files, or the same way that programs like mkvmerge can replace individual streams within their target media-container format? Static vs. dynamic linking is just about whether the top-level symbol table of the executable can be statically precomputed for that linkage. It doesn't impede you from re-computing the symbol table. That's what the linker already does, every time it links two compilation units together!
  • brianberns 5y ago
    Does a tool that can do this exist? A “relinker”? It’s a neat idea, but one obvious downside is the potential need to relink many executables when a shared component changes.
    • DoctorNick 5y ago
      there is, but nearly all of the ones I've seen are for reverse-engineering purposes.
    • ClumsyPilot 5y ago
      Ot seems you are getting downvoted, but for those of us who do not normally dive into the guts of executablea its a fair question
  • viraptor 5y ago
    More and more often they're not just isolated units. Link time optimisation can mess up that assumption and for example inline things across library borders.
• SavantIdiot 5y ago
  When was the last time you were able to swap a dynamic library and have things just work?
  • yjftsjthsd-h 5y ago
    Last time I ran apt upgrade?
  • pdkl95 5y ago
    Today, to get a game to work on an older system. Several times last week when I needed to use an old proprietary program that used several outdated libraries. Every single time I want to run a program (usually a game) that has a runtime dependency on pulseaudio[1]. (apulse[2] usually works to translate the libpulse ABI back to ALSA). One time I had to write my own version of a library that specifically emulated the ABI used by an important program from an outside vendor. Obviously this didn't "just work"; it required a couple weeks of work to write the new version. The point isn't that future versions of a library will magically "just work". With a dynamically linked dependency replacement is at least possible. If the program in question was statically linked, nothing could be changed. The question isn't about which method is less work or easier to maintain. The question that matters in the long run is if you want the basic ability to modify program's dependencies in the future to fix an important problem? [1] As of a few years ago, the stupid design decisions in pulseaudio make it make it highly incompatible with my needs. Just having it installed makes runtime linking issues even worse. It also add insane amounts of latency (>5ms is bad. >50ms is insane) by design. [2] https://github.com/i-rinat/apulse https://github.com/i-rinat/apulse
  • kingofpandora 5y ago
    All the time.
  • cbmuser 5y ago
    It happens almost every day when I update my rolling release distribution.
    • tlamponi 5y ago
• AussieWog93 5y ago
  If you need to change a statically built executable, you can always patch it manually. This was how no-CD cracks worked back in the day. Yes, dynamic linking makes this process easier, but it makes it so easy that both users and distro maintainers regularly break software without even realising it (hence why Red Hat use 5-year old versions of everything).
• jrockway 5y ago
  I don't think that being able to replace a library at runtime is a useful enough feature to justify the high maintenance cost of shared libraries. Like I complain about in a comment below, the cost of shared libraries is that an upgrade is all-or-nothing. If one program on your system depends on a quirk of libfoobar-1.0.3, and another program on your system depends on a quirk of libfoobar-1.0.4, you're fucked. You can't have both programs on your system, and Linux distributors will simply stop updating one of them until the author magically fixes it, which happens approximately never. And, the one they stop updating is the one that you want to update to get a new feature, 100% of the time. It's just not worth it. A binary is a closure over the entire source text of the program and its libraries. That's what CI tested, that's what the authors developed against, and that's what you should run. Randomly changing stuff because you think it's cool is just going to introduce bugs that nobody else on Earth can reproduce. Nobody does it because it absolutely never works. You hear about LD_PRELOAD, write some different implementation of printf that tacks on "OH COOL WOW" to every statement, and then never touch it again. Finally, dynamic loading isn't even the right surface for messing with the behavior of existing binaries. It has the notable limitation of not being able to change the behavior of the program itself; you can only change the results of library calls. I never want to see a dynamic library again. They have made people's lives miserable for decades.
  • zxzax 5y ago
    >If one program on your system depends on a quirk of libfoobar-1.0.3, and another program on your system depends on a quirk of libfoobar-1.0.4, you're fucked. You can't have both programs on your system, and Linux distributors will simply stop updating one of them until the author magically fixes it, which happens approximately never. I've not experienced that. If the package is maintained at all, then it will get updated. People are still somehow maintaining Perl 5 libraries and putting out bugfix releases, which are functionally equivalent to dynamic linking. If it's not maintained, then of course it will get removed from the distribution, for that and for a number of other reasons.
    • justinator 5y ago
      > People are still somehow maintaining Perl 5 libraries and putting out bugfix releases, which are functionally equivalent to dynamic linking. Not to be pedantic, but having multiple versions of any Perl library, or multiple versions of Perl on a single server without things getting stepped on is trivially easy. There's utils to switch Perl versions as well. I mean, it's Perl. Perl has a long, long, long history and culture of testing, backwards compatibility, Kwalitee Assurance, and porting to every system imaginable behind it as well, so if some Perl script from the 90's still runs with little to no modification, that should not exactly be seen as a rarity.
• matheusmoreira 5y ago
  > have reasonably stable ABIs So what libraries have this property? I've read in old threads about even glibc making changes that break binary interface compatibility. I get the feeling not much attention is paid to binary interfaces in the free software world.
  • cbmuser 5y ago
    > So what libraries have this property? I've read in old threads about even glibc making changes that break binary interface compatibility. You can request different ABI versions from glibc. And glibc doesn’t introduce breaking changes every day but rather every few years.
  • account42 5y ago
    Asides from rare bugs (which get fixed), glibc does not break ABI. However, glibc does extend the ABI with new versions so compatibility only goes one way - your runtime glibc (generally) needs to be at least as new as the one used for linking.
• foobar33333 5y ago
  > If the program is statically linked, then nothing can happen - either it works or it doesn't. With dynamic linking, changes are possible by changing which library is loaded. These problems are almost purely caused by dynamic linking though. The devs release something that was tested on some old version of ubuntu and now on your new fedora, things work different and the program is broken. While with static linking, it all just works.
  • jacquesm 5y ago
    It's not the program that is broken, it is the environment that is broken.
    • foobar33333 5y ago
      If by broken you mean having the latest features and security patches. Dynamically linked binaries are very fragile and not portable.
      • necovek 5y ago
        Latest features and security patches rarely go hand-in-hand: it's usually latest features and new security bugs instead. Developers want to maintain a single branch because that's much cheaper, not because it's the ultimate solution to all the problems of maintaining software.
  • necovek 5y ago
    You seem to be assuming that a statically linked library won't have a subtle, edge-case bug, when in fact, it doesn't just work. Even that could be env-related, so maybe it surfaced once you moved to a new Fedora release. Basically, the problems are pretty much the same with either approach, one has a more complex runtime environment, other has a more complex upgrade story. While I'd agree with Linus' take on shared libraries, I'd still say that "statically linked libraries are not a good thing in general either" (the stress is on general).
• duped 5y ago
  > The ability to change which library is being used without needing to rebuild the main program is really important. Having spent many hours avoiding bugs caused by this anti-feature I have to disagree. The library linked almost always must be the one that the software was built against. Changing it out is not viable for the vast majority of programs and libraries. Just as an example, there is no good technical reason why I shouldn't be able to distribute the same ELF binary to every distro all the time. Except the fact that distros routinely name their shared objects differently and I can't predict ahead of time what they will be, and I can't feasibly write a package for every package manager in existence. So I statically link the binary and provide a download, thereby eliminating this class of bug. Despite the rants of free software advocates, this solution is the one preferred by my users.
  • OnlyOneCannolo 5y ago
    Not defending it for general use, but dynamic linking can be very useful for test and instrumentation. Also sometimes for solvers and simulators, but that's even more niche.
    • Banana699 5y ago
      Can you please elaborate? Why would the ability to change the library version at runtime be useful for testing? and what aspect of this is useful for simulators and solvers?
      • dathinab 5y ago
        You compile a version of the dependency which intentionally behaves different (e.g. introduces random network errors, random file parsing errors, etc.) and "inject" it into a otherwise functional setup to check if all other parts including error reporting and similar work. There are always other ways to archive this but using (abusing?) the dynamic linking is often the simpler way to set it up. > and what aspect of this is useful for simulators and solvers? Duno, but some programs allow plugin in different implementations of the same performance critical functionality so that you can distribute a binary version and then only re-compile that part with platform specific optimizations. If that is what the author is referring to I would argue today there are better ways to do it. But it's still working out either way and can be much easier to setup/maintain in some cases. (And probably falls into the "shared libraries as extension system" category Linus excluded from his commentary.)
• e12e 5y ago
  > However, there important advantage of using .so files instead of building into a big statically linked binary is NOT that a library can be shared between different programs! The important benefit is dynamic linking. One could reasonably view the kernel use of loadable modules as an example of this utility.
• jayd16 5y ago
  DLLs and shared libraries are different things though, no? Isn't it common in windows to use DLLs and simply pack in everything you need? Is that not the best of both worlds minus a bit of ram and disk?
  • dathinab 5y ago
    DLL's are the windows version of shared libaries. Shared Objects (.so) are the Linux version of shared libaries. I.e. they are an implementation detail, and if you don't use them as "shared library" (in general) then it won't really fall under this category.
    • jayd16 5y ago
      Sure but the point is the predominant style on windows is to copy an exclusive version of needed DLLs and not share them.
      • CRConrad 5y ago
        The now predominant style. Windows DLLs didn't always used to be named Whatever_5_0_1.DLL; used to be it was just Whatever.DLL. Which lead to "DLL Hell" when the version of Whatever.DLL you had installed was not the same as the developer of your app had so the app wouldn't work, and if you switched to the one he had, some other app that used Whatever.DLL stopped working in stead. Which lead to the "exclusive version" / version-named DLL situation we have on Windows today... And, increasingly, on Linux. I don't know exactly how shared libraries are loaded -- there are some tantalising mentions in sibling comments -- but it all seems to point towards two opposite solution paths: 1) Version-named libraries like on Windows; and/or, possibly, some file-link magic where /std_shared_libs/somelibrary/somelib_x points to /actual_libs/somelibrary/somelib_x_y_z, etc, etc... Then you could also have .../somelibrary/somelib_latest point to, well, the actual latest version installed, and somelibrary/somelib_default point to the one you want as default, etc, etc. (Hmm... Shouldn't stuff like this have been hammered out decades ago by, Idunno, some kind of Linux standardisation initiative... if this doesn't exist already, then WTF is the LSB for?!?) 2) Just fucking static-link everything already. Friar William of Ockham seems to be pointing more towards one than the other of the above. Anyway, what certainly doesn't look like a great solution to me is 3) Containerization. That just feels like "In stead of fixing DLL Hell on Linux, let's just ignore it, replicate ~half the OS -- but with our preferred version of every library -- inside a (pseudo-)VM, and pretend that running boxes within boxes within boxes is a solution". No, that's not a solution, that's a kludge.
• m463 5y ago
  Maybe this is in-line with what Linus said (very standard libraries), but I think when there's a vulnerability in libssl.so being able to push a fix instead of having to fix many things is a huge win. The dependency hell thing seems to come up when libraries change their APIs and then you have to scramble. Last one I recall struggling with was libpng.so but there are plenty of others.
• dathinab 5y ago
  > really important. Except it isn't, at least not for open source. Most libraries do not have stable ABI's, even for C there are may ways you can mess that up. Even "seemingly clear cut cases" like some libc implementations ran into accidental ABI breakage in the past. And just because the ABI didn't change doesn't mean the code is compatible. It's not seldom that open source libraries get bugs because dynamic linking is used to force them to be used with versions of dependencies which happen to be ABI compatible (enough) but don't actually work with it/have sub-tile bugs. It sometimes gets to a point where it's a major anoyence/problem for some open source projects. Then there is the thing that LD_LIBRARY_PATH and similar are MAJOR security holes, and most systems would be best of to use hardening techniques to disable it (not to be confused with `/etc/ld.so.conf`). Through yes without question for not properly maintained closed source programs it is helpful. But then for them things like container images being able to run older versions of linux (besides the kernel) in a sandbox can be an option, too. Through a less ergonomic one. And not applicable in all cases.
  • ClumsyPilot 5y ago
    > "Most libraries do not have stable ABI's, even for C" I think the mess we created in ABI space is one of the failures of our indistry.
    • dathinab 5y ago
      I have maintained some mini projects which try to have strong API stability. And even through keeping API stability is much easier then ABI stability I already ran into gotchas. And that was simple stuff compared to what some of the more complex libraries do. So I don't think ABI FFI stability ever had a good chance (outside of some very well maintained big system libraries where a lot of work is put into making it work). I think the failure was to not realize it earlier and instead move to a more "message passing" + "error kernel" based approach for libraries where this is possible (which are surprisingly many) and use API stability only for the rest (except system libraries). EDIT: Like use pipes to interconnect libraries and use well defined (but potential binary) message passing between them. Being able to reload libraries resetting all global state, or run multiple versions of them at the same time etc. But without question this isn't nice for small utility libraries or language frameworks and similar.
• rualca 5y ago
  > (...) while the "couple of libraries that nobody else used. Literally nobody" should obviously be statically linked. I disagree. The main value proposition of shared libraries is being able to upgrade them without requiring to rebuild the application. Sure, libraries need to be competently maintained to ensure that patch releases are indeed compatible, but that still opens the door to fixing vulnerabilities on the fly by simply upgrading the lib that sneaks in the vulnerability, which shared libs allow even to end-users by simply dropping in a file.
• TomSwirly 5y ago
  > The ability to change which library is being used without needing to rebuild the main program is really important. In 40 years in the field, I've never needed that. Every single time, we just emitted an entirely new build - because it's _much easier._ > Maybe rebuilding the program isn't practical. Maybe rebuilding the program isn't possible because it's closed/proprietary or the source no longer exists These are edge cases. Nearly all the time when we develop, we are making changes in an existing codebase.
  • account42 5y ago
    > Every single time, we just emitted an entirely new build - because it's _much easier._ For you, the application developer. For end users of old or proprietary software, replacing libraries is much more feasible.