3 ms·

> Separating every dependency would be really inconvenient, just like managing graphical apps in a Linux distribution. If, for example, a flatpak named XYZ need

> Separating every dependency would be really inconvenient, just like managing graphical apps in a Linux distribution. If, for example, a flatpak named XYZ needs 10 dependencies, whereby one of the dependencies changes the version that the developers of the XYZ flatpak have not tested, then it could lead to bugs or even breakages that would make it really difficult for developers to trace back, as they would need to frequently contact each packager and figure out together. So, as mentioned by the author, the solution is to let the developers bundle everything, as they test their apps against an environment that is easier to understand. So why not just statically link at this point?

ben0x539 3y ago
There's still some reuse between flatpak apps, and not everything one might depend on necessarily is of the shape of a statically linkable library.
saidinesh5 3y ago
One main reason is licensing. Lots of good, basic libraries are lgpl. Like Qt etc... Also you'd want the basic libraries like glibc, ssl to be provided as shared libraries by the distros for various reasons - including security. That being said i do appreciate how newer languages like rust, go default to static linking.
- kelnos 3y ago
  > One main reason is licensing. Lots of good, basic libraries are lgpl. While this might be a little more annoying, you can absolutely statically link a proprietary application with an LGPL library. You do need to provide object files for the proprietary bits so someone could relink it with a different/modified version of the LGPL library, though. Which, yes, is annoying to the point that if I were distributing a proprietary application, I probably would use dynamic linking with the LGPL bits.
echelon 3y ago
It'd be neat if we could build binaries capable of both static and dynamic linking. Everything would be baked in statically, but you'd have the ability to override static links with system dynamic links at application launch. I'd like to be able to patch SSL bugs without downloading a whole new binary for everything that depends on it. But at the same time, I probably couldn't care less about other dependencies, and I don't want to sort out version mismatches and deal with system libraries in most cases. Ideally the operating system itself could help manage this. Know what deps I care to handle myself or override.
- seba_dos1 3y ago
  > It'd be neat if we could build binaries capable of both static and dynamic linking. Everything would be baked in statically, but you'd have the ability to override static links with system dynamic links at application launch. SDL works like that: https://github.com/libsdl-org/SDL/blob/main/docs/README-dynapi.md https://github.com/libsdl-org/SDL/blob/main/docs/README-dyna...
RaisingSpear 3y ago
> So why not just statically link at this point? In many cases, you just can't. Other than glibc having issues with static linking, you can't use `dlopen` in a static binary. For example, if you're building an application which can use OpenCL, you need to dynamically link to the ICD installed on the system. And because `dlopen` doesn't work in a static application, you're stuck with dynamic linking the whole application (or at least with libc). On the other hand, Windows has no issue with `LoadLibrary` in a static binary... I don't know enough about GUI applications, but I wouldn't be surprised if anything needing graphical output is in a similar boat. The cherry on top is that glibc doesn't make it easy for an application to be built for an older version of the library. As Linus Torvalds can attest to [https://www.youtube.com/watch?v=Pzl1B7nB9Kc https://www.youtube.com/watch?v=Pzl1B7nB9Kc] building for Linux sucks.
- arp242 3y ago
  You can statically link at least GTK applications (less sure about Qt, never tried), but many build systems don't support it very well and it requires some amount of hackery. The best trade-off is probably "link against libc, statically link everything else". That gives you dlopen() and some security benefits. But again, build systems don't support it very well out of the box. I think the outright hostility against static linking has been unfortunate, because now we have a whole bunch of "static linking, but with extra steps" systems to work around it. Dynamic linking is fine for many things, but it's obviously not always the best solution. It's disappointing that essentially nothing really improved in the 10 years since Linus gave that talk. Okay, there's flatpak and appimage and snap which are an "improvement" of sorts, but it's all pretty complex and half the time when I wanted to run one it didn't work well.

ben0x539 3y ago

There's still some reuse between flatpak apps, and not everything one might depend on necessarily is of the shape of a statically linkable library.

saidinesh5 3y ago

One main reason is licensing. Lots of good, basic libraries are lgpl. Like Qt etc... Also you'd want the basic libraries like glibc, ssl to be provided as shared libraries by the distros for various reasons - including security. That being said i do appreciate how newer languages like rust, go default to static linking.

kelnos 3y ago
> One main reason is licensing. Lots of good, basic libraries are lgpl. While this might be a little more annoying, you can absolutely statically link a proprietary application with an LGPL library. You do need to provide object files for the proprietary bits so someone could relink it with a different/modified version of the LGPL library, though. Which, yes, is annoying to the point that if I were distributing a proprietary application, I probably would use dynamic linking with the LGPL bits.

echelon 3y ago

It'd be neat if we could build binaries capable of both static and dynamic linking. Everything would be baked in statically, but you'd have the ability to override static links with system dynamic links at application launch. I'd like to be able to patch SSL bugs without downloading a whole new binary for everything that depends on it. But at the same time, I probably couldn't care less about other dependencies, and I don't want to sort out version mismatches and deal with system libraries in most cases. Ideally the operating system itself could help manage this. Know what deps I care to handle myself or override.

seba_dos1 3y ago
> It'd be neat if we could build binaries capable of both static and dynamic linking. Everything would be baked in statically, but you'd have the ability to override static links with system dynamic links at application launch. SDL works like that: https://github.com/libsdl-org/SDL/blob/main/docs/README-dynapi.md https://github.com/libsdl-org/SDL/blob/main/docs/README-dyna...

RaisingSpear 3y ago

> So why not just statically link at this point? In many cases, you just can't. Other than glibc having issues with static linking, you can't use `dlopen` in a static binary. For example, if you're building an application which can use OpenCL, you need to dynamically link to the ICD installed on the system. And because `dlopen` doesn't work in a static application, you're stuck with dynamic linking the whole application (or at least with libc). On the other hand, Windows has no issue with `LoadLibrary` in a static binary... I don't know enough about GUI applications, but I wouldn't be surprised if anything needing graphical output is in a similar boat. The cherry on top is that glibc doesn't make it easy for an application to be built for an older version of the library. As Linus Torvalds can attest to [https://www.youtube.com/watch?v=Pzl1B7nB9Kc https://www.youtube.com/watch?v=Pzl1B7nB9Kc] building for Linux sucks.

arp242 3y ago
You can statically link at least GTK applications (less sure about Qt, never tried), but many build systems don't support it very well and it requires some amount of hackery. The best trade-off is probably "link against libc, statically link everything else". That gives you dlopen() and some security benefits. But again, build systems don't support it very well out of the box. I think the outright hostility against static linking has been unfortunate, because now we have a whole bunch of "static linking, but with extra steps" systems to work around it. Dynamic linking is fine for many things, but it's obviously not always the best solution. It's disappointing that essentially nothing really improved in the 10 years since Linus gave that talk. Okay, there's flatpak and appimage and snap which are an "improvement" of sorts, but it's all pretty complex and half the time when I wanted to run one it didn't work well.