4 ms·

Don't forget that the principles of the LGPL (originally the "library GPL") were/are pretty much tied to the technical concept of a shared library object that a

Don't forget that the principles of the LGPL (originally the "library GPL") were/are pretty much tied to the technical concept of a shared library object that an end-user can change, etc; IANAL so I can't say anything about the legal soundness of this interpretation. Moreover, in a recent discussion about this topic on HN, someone said the introduction of shared libs into the Linux user space was mainly in support of porting X Windows to Linux (supposedly because of binary video drivers or to accomodate MIT-licensed code?), but I haven't found any supporting reference for that. glibc's maintainer Ulrich Drepper also has pretty strong opinions on static linking [1]; no matter what you think about this technically, or Ulrich personally, his paper "How to write shared libraries" [2] is considered reference material on the subject. Personally, I think that the over-use of shared libs in the Linux userland clearly serves no purpose if users flock to entire new layers of abstractions (eg Docker-like containers) to isolate their app delivery from the IMHO overengineered mechanisms in ELF and ld.so with their multiple RUNPATHs, configs, loader scripts, and versioned glibc symbols (on top of build-time libtool/autootols) that still doesn't seem to get to the point. While the LSB effort for more uniform Linux distros isn't dead, it doesn't seem to be taken seriously. Idk, but maybe the GNU folks also see the lack of binary compat for Linux apps as a desideratum, to frustrate any and all attempts to ship binary apps? [1]: https://web.archive.org/web/20100527213559/http://people.redhat.com/drepper/no_static_linking.html https://web.archive.org/web/20100527213559/http://people.red... [2]: https://akkadia.org/drepper/dsohowto.pdf https://akkadia.org/drepper/dsohowto.pdf

pjmlp 6y ago
Without shared libraries, the only way to do plugins is via IPC. Sure it is more secure and probably preferable in modern times, but it also slower and requires more hardware resources, specially when one scales it with desktop software running hundreds of processes, each for their own plugin sets. There is no free lunch as they say.
- 08-15 6y ago
  > Without shared libraries, the only way to do plugins is via IPC. That's primitive superstition: - dlopen() works in statically linked programs too. - Even without dlopen(), you can load code dynamically. It's not magic, especially if the plugin is linked statically. - Besides, how is IPC bad? I take fcgi over Apache's modules any day.
  - pjmlp 6y ago
    dlopen is useless in static linked programs when the idea is to provide plugins after the fact. The idea of using plugins is exactly that various parts are able to ship them at various times during the lifetime of the applications. Patching files compiled statically is obviously not what one wants from plugins. Incidently plugins support is exactly why Go added support for dynamic linking into their toolchain.
    - 08-15 6y ago
      One of us is confused; I honestly don't know which one. Where is the problem in this scenario? My application (statically) linked provides a plugin interface. It works by calling dlopen() on the plugin and then passes a record of functions to the entry points. The plugin can be provided by a third party, and top make that easier, I provide an SDK (a header file). No file is patched, and I have no idea what this has to do with Go. Enlighten me?
      - pjmlp 6y ago
        Your solution requires compiling everything from scratch in a single executable, that is not how plugins are supposed to be designed. We have been there before with solutions like graphics drivers for Borland's BGI library for their MS-DOS compilers. Where a driver interface is provided, and then each "plugin" registers themselves on application startup. Adding new plugins to an existing application in this scenario requires recompilation and updating the uses/#include being used for plugins, or patch the executable from an existing .obj file. If you are using dlopen on a third party binary instead of your own, then you are already using dynamic linking by definition, by loading third party code dynamically and revolving the proper address locations for all symbols. Go only had static compilation on the beginning as the only true way, but it failed short exactly in this scenario, to the point that eventually plugin package came to be and dynamic compilation support is now a feature of Go's toolchain as well, although many seem to still not be aware that Go compilers can also produced dynamic libraries.
        6y ago

pjmlp 6y ago

Without shared libraries, the only way to do plugins is via IPC. Sure it is more secure and probably preferable in modern times, but it also slower and requires more hardware resources, specially when one scales it with desktop software running hundreds of processes, each for their own plugin sets. There is no free lunch as they say.

08-15 6y ago
> Without shared libraries, the only way to do plugins is via IPC. That's primitive superstition: - dlopen() works in statically linked programs too. - Even without dlopen(), you can load code dynamically. It's not magic, especially if the plugin is linked statically. - Besides, how is IPC bad? I take fcgi over Apache's modules any day.
- pjmlp 6y ago
  dlopen is useless in static linked programs when the idea is to provide plugins after the fact. The idea of using plugins is exactly that various parts are able to ship them at various times during the lifetime of the applications. Patching files compiled statically is obviously not what one wants from plugins. Incidently plugins support is exactly why Go added support for dynamic linking into their toolchain.
  - 08-15 6y ago
    One of us is confused; I honestly don't know which one. Where is the problem in this scenario? My application (statically) linked provides a plugin interface. It works by calling dlopen() on the plugin and then passes a record of functions to the entry points. The plugin can be provided by a third party, and top make that easier, I provide an SDK (a header file). No file is patched, and I have no idea what this has to do with Go. Enlighten me?
    - pjmlp 6y ago
      Your solution requires compiling everything from scratch in a single executable, that is not how plugins are supposed to be designed. We have been there before with solutions like graphics drivers for Borland's BGI library for their MS-DOS compilers. Where a driver interface is provided, and then each "plugin" registers themselves on application startup. Adding new plugins to an existing application in this scenario requires recompilation and updating the uses/#include being used for plugins, or patch the executable from an existing .obj file. If you are using dlopen on a third party binary instead of your own, then you are already using dynamic linking by definition, by loading third party code dynamically and revolving the proper address locations for all symbols. Go only had static compilation on the beginning as the only true way, but it failed short exactly in this scenario, to the point that eventually plugin package came to be and dynamic compilation support is now a feature of Go's toolchain as well, although many seem to still not be aware that Go compilers can also produced dynamic libraries.
      - 6y ago