MeeGo Compliance: /opt and LD_LIBRARY_PATH

April 6, 2011

Last time I described how to use LD_LIBRARY_PATH for your private libs in your package. While this will usually get you what you want, it has one extremely big drawback: poisoning 3rd party libs. It also has one minor drawback: applications start up slower.

Starting Slower

When your application starts, a program called ld.so looks to see what libraries you need. (E.g. libQtCore.so.4 and libxml2.so.0 and so forth.) Since this happens all the time, it keeps an index of these libraries and where they are located. Thus, it’s able to resolve the libraries very fast.

But when you set LD_LIBRARY_PATH, these paths have to be searched first, and this is slower because you actually have to access the file system and search directories.

But this is only a minor problem… the bigger problem is…

Poisoning 3rd Part Libraries

To be MeeGo compliant, there is a prescribed list of libraries that we can depend on. For everything else, we have to bring our own. Suppose, for instance, that MeeGo’s version of libAtion.so.1 does not have all the features that you need. So, you package your own version of libAtion.so.1 with the extra features and ship it as a private library in your package.

Meanwhile, Qt is already linked to libAtion, and you use it (indirectly) in your code. When your program is initialized, it’ll see that Qt needs libAtion.so.1 and use your private version instead of the system version that Qt shipped with. Do you see how this might cause problems?

Or, suppose you had no idea that libAtion.so.1 was in any MeeGo, anywhere. However, DeviceMan, Inc. shipped a MeeGo device where they added libAtion.so.1 as part of their default Qt theme plug-in. Now when your application loads the theme, it is poisoned with your private libAtion.

Solutions to LD_LIBRARY_PATH

So, LD_LIBRARY_PATH isn’t the best solution (and some will say it is to be avoided at all costs). What other options do you have?

  • Statically link your programs to your private libraries — While this isn’t as convenient to your opt/non-opt build workflow, it is effective.
  • Use rpath when you link — the GNU linker has an -rpath option that is like setting LD_LIBRARY_PATH at compile time. The advantage is that it only applies to your binary… and not other 3rd party libs.
  • Do lots of homework — Make sure that your version is compatible with whatever version may be on the system. If possible, prefer the system’s version of the library. However, this option is destined to fail, eventually.

Further Reading

I found the following articles informative:

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: