Yesterday, I did an in-house distribution of a LSB compliant Qt binary. It worked on all the LSB 3.0 compliant systems we have here, and with some smaller “workarounds” (aka hacks), also on LSB 2.0 systems.
Building an LSB-complying Qt app is easy. Grab the lsb build environment from linuxbase.org (you need the latest lsb-build-*.rpm) and add /opt/lsb/bin to your PATH. To build an LSB app, you should use lsbcc instead of gcc. If you’re following the recent Qt snapshots, you might have noticed a new qmake spec called linux-lsb. Setting the environment variable QMAKESPEC to linux-lsb will tell qmake to compile with lsbcc instead of gcc.
After the environment is set up, all there is to do is a qmake && make. If the project links to non-LSB certified libraries, lsbcc will automatically link them statically to make sure that the resulting binary does not rely on libraries/symbols that might not exist on all distributions.
Deployment is a bit trickier. The lsb-desktop standard is not released yet, so we have to ship our own LSB-conforming Qt. This is easily done by building Qt itself with the linux-lsb makespec and with rpath support (since we don’t want to install it into /usr/lib).
Here are the commands I used to create the binary:
./configure -platform linux-lsb -release -no-qt3support --prefix=/opt/myapp
sudo make install_qmake install_mkspecs
sudo make -C src install
sudo cp myapp /opt/myapp/bin
For the package, you need /opt/myapp/lib/libQt*.so.4, the /opt/myapp/plugins directory and /opt/myapp/bin/myapp. Since Qt was built using --prefix, it sets an rpath when linking your application, so you don’t need to worry about LD_LIBRARY_PATH when executing your application.
After everything is built successfully, we need to create an RPM package. The LSB book has a nice example how to do so. To install the RPM on Debian-based systems, you can use alien -i.
Unfortunately, Kubuntu doesn’t support LSB 3.0 yet, but with a small and evil hack, it’ll run our application (sudo ln -s /lib/ld-lsb.so.2 /lib/ld-lsb.so.3).