Hacker News Reader

Comment by chrisseaton | Hacker News Reader

> So now the solution is AppImages where you bundle up your app with all dependencies like a container.

But isn't this what you're doing with Windows? No version of Windows comes with libcurl (as far as I know) so you put the DLL in your application directory. It's no different.

View on HN

On Windows, I use the Windows API for downloading files. I don't need to worry about curl.

On Linux, I could have statically linked curl, but didn't realize it was going to become an issue. Ubuntu 18.04 was released and curl3 was removed, so that means our software that was working was either automatically removed by the package manager or it started crashing.

Can a installer prompt user to download missing libraries if needed? For example - Dota2 on Windows downloads bunch of C++ runtime libraries on first launch. Sharpkeys and bunch of other software do that (certain version of .net runtime).

libcurl may or may not be a good example but surely all software has dependencies that isn't shipped with OS. In Linux case the special pain is, library that is shipped with OS might be outdated but bundling compiled lib/o/so files should work.

On Windows, I often get prompted to install C++ runtime dependencies when installing. One big thing Steam did was manage multiple installs of DirectX for each game. It's just a matter of Linux being cost/benefit to overcome these things, like they have on Windows.

Which is probably way at the back of the developer's minds: the main audience of Linux is happy to compile from source (either themselves or via a downloaded package).

Exactly. Quite a few of the "problems" with Linux development ultimately stem from trying to shoehorn Windows-oriented expectations into Linux development/deployment. Very few applications in the Linux world target specific distros themselves; instead they publish their source code and leave the actual distro-specific finagling to distro/package maintainers (sometimes those maintainers are also developers, but they're regardless treated as separate concerns).

Of course, quite a few game developers are curiously averse to publishing any kind of source code, which tends to thus require compatibility efforts to happen on the developer side instead of the package maintainer side. This can still be worked around by targeting a specific distro (say, Ubuntu or SteamOS) and letting package maintainers for other distros apply whatever workarounds they deem necessary to get the app running outside of a "supported" environment (see also: Steam, Spotify, Slack, etc.).

I'll grab source code if I'm doing development or something obscure, but I feel like packages have been pretty solid and widely available since the early to mid 2000s. When working with source code I'll almost always install to a custom PREFIX--but if it's just an app the source is the last resort.

All of the commercial packages I've used at work for the past 15 years target either one or a handful of distros. Even the open source stuff that's either too new or outside of the default repos I much prefer to install from a package; turbovnc, grafana, chrome, etc. The few games I've seen have worked the same way as other commercial user-oriented apps.

You don't have to statically link, you can use LD_PRELOAD to point to local versions of all libraries. It isn't optimal, from space/security perspectives, but it works. You can use the local libs first or last in the path.

You don't even have to do that. When you compile your binary you just need to set the rpath to your own directory of libs and they will be search automatically and fall back to the system if missing.

Last time I looked the rpath is a static absolute path, which is inconvenient if you want to install the libraries elsewhere.

The automatic fallback to system libraries can also lead to mysterious problems.

The linker recognizes a variable that expands to the location of the binary so you can use relative paths.

${ORIGIN}/lib will be the relative library path.

Fascinating.

Some useful stack overflow answers on this topic. First, the trick to get GCC to pass the ORIGIN option to the linker: -Wl,-z,origin.

Secondly, how to pass it as the rpath option:

"-Wl,-rpath,'$ORIGIN' -- note that you need quotes around it to avoid having the shell interpret it as a variable, and if you try to do this in a Makefile, you need $$ to avoid having make interpret the $ as well."

https://stackoverflow.com/questions/38058041/correct-usage-o...

The chrpath utility is also fascinating, as it allows you to rewrite the elf headers to change the rpath. Possibly better for installs than passing lots of env variables.

Various warnings on this topic to not use actual relative paths unless you really want that behaviour.

Reply on news.ycombinator.com