Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm packaging an application for the first time for Ubuntu. I have a few dependencies, the primary ones being Qt and ICU. I'm just not clear how to deploy these applications without getting into a kind of dll-hell for Linux.

For example, I would like to use version 4.7.4 of Qt because there are some bug fixes in that release that I would like to take advantage of. I would also like to deploy my application on all the currently supported versions of Ubuntu, which takes me back to Lucid. But the latest version available for Lucid is 4.6.2, which isn't even API-compatible with 4.7.4. The options, as I see it:

  • Just say "tough" and only support Ubuntu versions that have the library I need, which would mean Oneiric at this point. For earlier versions, they are on their own to find a 4.7.4 library and resolve all its dependencies.
  • Provide private versions of the library, say libQtCore4_mycompany, and a package to install them.
  • Stick a private version of the assembly side-by-side with my application (perhaps /opt/company/package/lib) and set LD_LIBRARY_PATH before executing my application.

None of these are great options, and in particular, debuild is awful to use if you depart in the slightest bit from their expectations. I cannot link statically because of LGPL restrictions (at least, that's how I understand them.)

I also have the reverse question. Suppose I decide to put a dependency on libQtCore4 (>= 4.7.4). I have seen enough regressions between Qt versions that there is a chance that 4.7.5, or 4.8.0, will break something in my application. Is that just something you have to deal with, or is it a best practice to depend on an exact version of the library, like libQtCore4 (= 4.7.4)?

share|improve this question
up vote 1 down vote accepted

If you really want to support releases that don't have the required library version, then just use static linking. Having a shared library that you are the only user of defeats the purpose of shared libraries, so you may as well just put it all in one binary. You will even save some space since the parts of the library you don't call will be thrown out.

I would suggest that you start with an oneiric build that just lists the depend normally, then switch to static linking when you backport it to older releases.

share|improve this answer
I should have added to the original question: I can't (legally) static link, because of LGPL restrictions on Qt. – Dave Oct 5 '11 at 15:50
@Dave, are you sure? I thought that the LGPL specified that linking in general was allowed, not just dynamic linking? If that is the case, then I guess you will have to go for the private build of the shared lib. – psusi Oct 5 '11 at 18:06
Yeah, the license is confusing. There is a clause that demands that others be able replace the version of the library you are using with one they built themselves. Many (though it is certainly not unanimous) infer that this precludes static linking, since there is no way they could do that without rebuilding your code as well. – Dave Oct 5 '11 at 20:54
@Dave, or you could do like the video driver guys do; provide your code as a compiled object file so people can statically link it to the library themselves ( if they want to use a different library version ). – psusi Oct 6 '11 at 23:53
The LGPL does allow static linking, but it requires that you then provide the object files so that the user can relink them against a newer version of the library. – Grumbel Nov 16 '11 at 17:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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