0

First of, I've found this similar question How to make a portable Linux app? but it doesn't really address my questions, it's more about how to compile to make the application portable which I already know how to do (at least I think I do) and not about deployment as I will explain below.

This is my situation. We've been hired to solve a certain problem for a client, so we'll be developing a closed source application which we intend to sell to them. However, we have not been given any specifics about where it should be able to run, with that I mean what distribution, kernel version or anything really. The task is fairly simple and doesn't depend on any low level drivers or anything that would complicate making it portable. We do however depend on a couple of 3rd party libraries, the following is a simple scheme of the dependencies:

app --+-- libA
      |          +-- lib1
      +-- libB --+-- lib2
                 +-- lib3

Where libA,B and lib1,2,3 are all open-source projects with suitable licenses (LGPL, ASL and BSDs). Once compiled, the shared dependencies of our program become libA, libB, lib1, lib2, lib3 and a bunch of system libraries such as libc, libm, libz, libstdc++, libpthread, etc. Everything is linked dynamically.

Now, since we don't have a target distribution we want to keep this independent of any packaging system like .deb or the like. The direct dependencies (libA and libB) are not very common, so the obvious choice is to deliver them altogether with our application. lib1,2,3 are actually more common (ie one of them is libpng) although still not certain they'll be installed in the target system. We've decided to include all 5 of them in the final software package.

What we have no idea what to do with is the system libraries. How should we handle this? Do we just assume they'll have the correct libraries and pray for the best? In such case, what would happen in a year or two when one of those libraries changes and our application stops working?

Should we distribute all of them (libstdc++, glibc, etc) with our software? This doesn't feel right and I think it might be going against the licensing terms in them. I know I've used some programs in the past which actually carried their own copy of [at least] some of those libraries, it actually caught my attention because it was an older version than the one in my system and interchanging them made everything stop working (which I found out by accident).

How is this usually handled?

closed as too broad by Basile Starynkevitch, Satō Katsura, phk, Kusalananda, EightBitTony Jun 2 '17 at 11:41

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    "what would happen in a year or two when one of those libraries changes and our application stops working?" seems to answer itself. – Michael Homer Jun 2 '17 at 4:24
  • Without a concrete explanation of what your software is actually doing and what very practically are the various libraries (e.g. what exactly are libA, libB, lib1, lib2, lib3) you won't get any useful help. I recommend to edit your question to improve it and tell much more about your actual program. – Basile Starynkevitch Jun 2 '17 at 4:34
  • @BasileStarynkevitch Does it matter what those libraries do? We already know we will bundle those with the software because they aren't standard in any distribution. My question is about the system libraries (libstdc++, glibc, libz, etc). – sycc90 Jun 2 '17 at 4:38
  • Yes it does matter a lot. System libraries don't mean anything, except that they are installed in /usr/lib or /usr/lib/x86_64-linux-gnu/ and provided by the distribution. – Basile Starynkevitch Jun 2 '17 at 4:38
  • Actually, now that I think about it, it might even be a software with no 3rd party dependencies at all (other than system libraries). My question still stands, what to do with those? – sycc90 Jun 2 '17 at 4:40
1

The strictly correct approach to portable binary executables on Linux is to work against the Linux Standard Base and its detailed specifications. The LSB is designed to produce binary compatibility across compatible distributions by specifying specific library versions (or compatibility with those versions). The LSB (or at least a past version) was formalised as ISO/IEC 23360. If you build your program to link against only LSB libraries (and those it ships itself), it will be portable between all those systems.

The LSB specifies the RPM format for packages, so you only need to produce one (strictly). A tarball will suffice as well, if you forego the integration with the package manager.

In regards to some of your specific points:

Do we just assume they'll have the correct libraries and pray for the best?

A fairly simple LSB-compatible program will likely run on many systems as-is, so you could do.

In addition to that, several distributions attempt to provide LSB compliance, including RHEL and SUSE. Some others offer it through a specific package that pulls in the appropriate dependencies. For example, Debian has a package lsb that pulls in lsb-core and several others, which in turn pull in the appropriate dependencies. It's possible that the target systems might need to install such a package to run your software.

The LSB is less popular than it once was and formal compatibility has waned for a lot of systems, but in practice it is possible to run portably across a fairly wide range. Even some systems that do aspire to compliance miss some of the more obscure points, but for common purposes it often doesn't matter (and the same programs may work on systems that don't attempt to be LSB-compliant).

In such case, what would happen in a year or two when one of those libraries changes and our application stops working?

When your application stops working your application will stop working. This is a business process question.

Should we distribute all of them (libstdc++, glibc, etc) with our software?

Probably not. For libc, in particular, there can be run-time compatibility issues when using multiple versions at once on a system. There are other libc implementations that may be more practical to bundle, however.

While most libraries can be successfully bundled, vendoring libraries is a maintenance and security issue in general, so I would advise against doing so wherever it can be avoided. If a bug or security flaw is discovered in a library, updating it in one place on the system, which the distribution will address, is easier and more reliable than tracking down every copy (and getting replacement packages from you!).


As a more practical step, perhaps ask your client where they want it to run. You may be being over-enthusiastic.

0

In practice you'll need to make several binary packages (e.g. .deb for Debian and Ubuntu, .rpm for Fedora) for the most common Linux distributions (and versions). Obviously you'll need to make different packages for Fedora and for Ubuntu, and you might need to make a different package for Debian Jessie & Ubuntu 16.04. However, sometimes a package for Ubuntu might be installed on some (particular) Debian or vice versa.

However, we have not been given any specifics about where it should be able to run, with that I mean what distribution, kernel version or anything really.

You need to discuss with your client.

In such case, what would happen in a year or two when one of those libraries changes and our application stops working?

You'll need to build and release newer variants of your binary packages, and you will spend efforts (& money) for that.

You may want to link (if technically and legally possible) some libraries statically (remember that the LGPL license recommend to link dynamically, or else to be able to relink statically on client machine). For example libstdc++ is much more sensitive to versions than the libc so you might link statically libstdc++ and dynamically libc. In reality YMMV.

Notice that having several versions of a given system library may or may not work in practice. Some libraries are using system resources in a specific way, so details matter a lot.

PS. Maybe you should discuss more with your client and offer to make a free software (open source). Some clients might prefer that.

  • But is there a reason to make several packages if only one (containing the required libraries) would work just fine? – sycc90 Jun 2 '17 at 4:20
  • About your second point, having your software automatically break if the client updates his system is a no-go in the industry, we can't have that at all. That is, assuming an update to a library (say libstdc++) could break the program, a major distribution upgrade certainly doesn't fall into the same category. – sycc90 Jun 2 '17 at 4:24
  • I don't see any reason that the first paragraph is necessarily true. – Michael Homer Jun 2 '17 at 4:25
  • Then you are screwed. But you could contractually write that your package is working only for such and such particular version of distribution. If your client is still upgrading (major upgrade of distribution, ie Ubunut 16.04 -> 17.10) it is his responsibility – Basile Starynkevitch Jun 2 '17 at 4:25
  • 1
    @sycc90 The premise of your question is that the application will stop working at that time. What answer do you expect? – Michael Homer Jun 2 '17 at 4:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.