3 ms·

> but if we want good cross-distribution support we're still going to be limited to what's shipping in the oldest supported version of RHEL. Why should that re

> but if we want good cross-distribution support we're still going to be limited to what's shipping in the oldest supported version of RHEL. Why should that requirement be considered so extreme when, in the Windows world, applications are often required to work as far back as Windows 7 (or were until a year or two ago)?

nousermane 5y ago
On Windows, .dll files are automatically searched in quite a few places, including current directory, directory where .exe was launched from, and PATH environment variable. Meaning it is far easier for apps to ship private libraries. Plus, when linux apps try to ship private libraries, as official chrome packages do, that gets quite some backlash from distro maintainers.
- account42 5y ago
  > On Windows, .dll files are automatically searched in quite a few places, including current directory, directory where .exe was launched from, and PATH environment variable. Meaning it is far easier for apps to ship private libraries. You can get the same behavior on Linux by linking with -Wl,-rpath,\$ORIGIN (minus the PATH env var, use LD_LIBRARY_PATH for that).
- Joker_vD 5y ago
  And on Windows the default way to bundle an application is "make a separate directory for that application, put everything you need inside it" which is kinda equivalent to Linux "/opt" packages, IIRC? Anyway, that neatly combines with the lookup rules for .dlls (they're first searched next to the executable file itself) so that shipping mostly self-contained applications is sorta easy: the applications by default use their packaged libraries, and if those are missing, the system libraries or libraries from PATH are used.
mjg59 5y ago
I'm trying to scope the "Just use system libraries" approach into one that's realistically achievable. I agree that this shouldn't be an extreme requirement, but it turns out that most app authors aren't terribly interested in restricting themselves to the libraries shipped in RHEL 7, so.
yoz-y 5y ago
But on Windows most applications bring in copies of all of their dependencies. And ask for a 20th version of VC redistributable to be installes.

nousermane 5y ago

On Windows, .dll files are automatically searched in quite a few places, including current directory, directory where .exe was launched from, and PATH environment variable. Meaning it is far easier for apps to ship private libraries. Plus, when linux apps try to ship private libraries, as official chrome packages do, that gets quite some backlash from distro maintainers.

account42 5y ago
> On Windows, .dll files are automatically searched in quite a few places, including current directory, directory where .exe was launched from, and PATH environment variable. Meaning it is far easier for apps to ship private libraries. You can get the same behavior on Linux by linking with -Wl,-rpath,\$ORIGIN (minus the PATH env var, use LD_LIBRARY_PATH for that).
Joker_vD 5y ago
And on Windows the default way to bundle an application is "make a separate directory for that application, put everything you need inside it" which is kinda equivalent to Linux "/opt" packages, IIRC? Anyway, that neatly combines with the lookup rules for .dlls (they're first searched next to the executable file itself) so that shipping mostly self-contained applications is sorta easy: the applications by default use their packaged libraries, and if those are missing, the system libraries or libraries from PATH are used.

mjg59 5y ago

I'm trying to scope the "Just use system libraries" approach into one that's realistically achievable. I agree that this shouldn't be an extreme requirement, but it turns out that most app authors aren't terribly interested in restricting themselves to the libraries shipped in RHEL 7, so.

yoz-y 5y ago

But on Windows most applications bring in copies of all of their dependencies. And ask for a 20th version of VC redistributable to be installes.