0

I'm trying to do a Linux release for a piece of Qt software, but I'm a clueless Linux newbie. I've built my application with the Qt libraries statically linked, and made .deb and .rpm packages, but when I test them I get warnings about missing libraries on some distributions. For example, my .deb version runs fine on Debian and Ubuntu, but it doesn't start on Linux Mint KDE due to missing libraries. Running ldd I find there are four missing libraries:

libpng16.so.16 => not found
libicui18n.so.57 => not found
libicuuc.so.57 => not found
libicudata.so.57 => not found

Clearly I need to somehow ensure all the necessary library are present, however the list of libraries required seems to vary. For example Linux Mint Cinnamon lists 33 libraries, while Ubuntu Unity lists 34 (libpng12.so.0 is the extra one). I also assume that some of those libraries are standard Linux libraries that would come with all distributions so I wouldn't need to include them.

I don't really know what I'm doing, so a few questions:

What is the best way to determine the list of libraries I need to include with my .deb and .rpm packages? If ldd is the best option, do I need to include all the listed libraries or are there some that are bundled as standard with all Debian/rpm distributions?

What is the best way to to include those libraries? Do you include them in the package or specify them in the dependency list?

Any other general advice would be appreciated because I'm not really sure I'm going about this the right way.

Thanks.

Leagram
  • 15
  • 4
  • 3
    And did you add proper dependencies for your packages? You really should list *all* dependencies you have, even for those packages that are "standard" or "system". – Some programmer dude Aug 18 '17 at 11:10
  • Different Linux distributions have different libraries. An rpm built on Fedora is unlikely to install on CentOS or RHEL, and vice versa. Ditto for deb. The only practical way to distribute your codez on Linux is as source code. That's what Linux is designed for: free software, distributed as source code. The most that can be achieved is to build a software on an old version of a given Linux distribution, which should be installable on the later version -- but of the same Linux distro only -- since binary ABIs are generally backwards compatible. – Sam Varshavchik Aug 18 '17 at 11:11
  • https://stackoverflow.com/a/33837854/412080 – Maxim Egorushkin Aug 18 '17 at 11:14
  • @Someprogrammerdude I have included all dependencies now, but it still didn't seem to work (more details in the reply to Rodger below). – Leagram Aug 20 '17 at 07:57
  • @SamVarshavchik Thanks a lot for your recommendation about building on an old version. I was building on Debian 9.1, but switch to 8.4 and now it runs fine on Ubuntu and Mint. Also, the application is open source, but I wanted to provide binaries for popular distributions. – Leagram Aug 20 '17 at 08:02

1 Answers1

1

Don't think about library dependencies; think about package dependencies.

When you create your (deb, rpm) package, you can list other packages that it depends on. Figure out which package has your desired library in it, and add that package as a dependency.

Then, when the user installs your package, their package manager will also, if it needs to, install the packages that it depends on. Presto: you have the libraries you need.

Roger Lipscombe
  • 89,048
  • 55
  • 235
  • 380
  • Thanks, I found the apt-file program which tells you which package a library is in on Debian. I included all the packages in the dependency list, but when I ran on Linux Mint I was still getting dependency issues, even though the library was clearly installed. As Sam Varshavchik suggested in his comment above, it seems the solution is to build on an old version of the distribution. I was building on Debian 9.1 but after changing to 8.4 the issues appear to be resolved. That's the .deb build sorted, so I'll go and try the .rpm version now. – Leagram Aug 20 '17 at 08:08