Qt binary package on different distributions - problem

[Tux-Slack]

Hello everyone!

I'm having problems with my app and libraries.
For my application I provide the source code to be compiled and a binary package with a BitRock InstallBuilder GUI installer for those people who don't have Qt4 or don't know how to compile programs on Linux.
I'm compiling on a Slackware 12 machine and doing the package. But now an Ubuntu user downloaded this package and installed it. But now it shows that libssl.so.0 is missing, but it is not missing, it's just on another place than in Slackware.
Slack: /usr/lib
Ubuntu: /usr/lib/i686/andsomething


How would I fix this problem on the fast way? I already have a long term plan, but it's not yet doable and will happen upon next release.

[jacek]

A quick solution is to use LD_LIBRARY_PATH.

For real solution see this: http://labs.trolltech.com/blogs/2006/05/09/deploying-qt-applications-on-linux/ (but I'm not sure if slackware conforms to LSB).

[bitrock]

Hi,

As jacek mentioned, LSB may be able to help but the problem is that OpenSSL is not part of the LSB spec. The most common solutions are either:
- Compile statically
or
- You can ship the libraries that your app depends on, use a wrapper script and LD_LIBRARY_PATH to point to that directory

You may also want to compile on an older system such as Red Hat 9 or Debian 3.1 that uses an older version of glibc and RedHat

Best regards

Daniel

[Tux-Slack]

Yes well, Slackware isn't LSB compilant.
Can I ship OpenSSL libs with a GPL program?

[Brandybuck]

/usr/lib/i686/andsomething is not a standard location. Not in the least. The bug belongs to Ubuntu (and possibly Debian, if that's where it comes from). I would fire off a nasty note to Ubuntu, citing the FHS standard.

But your users won't care who's responsible for the bug, so you still need to deal with it. Sigh. There's no shortcut to testing your application under all major distributions and their variants. In some ways, Linux fragmentation is worse than the old Unix fragmentation, because standards are being deliberately ignored.

[Tux-Slack]

Well there is a /usr/lib/libssl.so.0.9.8 on Ubuntu. But my app is looking for /usr/lib/libssl.so.0 which is a symlink to /usr/lib/libssl.so.0.9.8 on Slackware.

[nooky59]

Hi,

As jacek mentioned, LSB may be able to help but the problem is that OpenSSL is not part of the LSB spec. The most common solutions are either:
- Compile statically
or
- You can ship the libraries that your app depends on, use a wrapper script and LD_LIBRARY_PATH to point to that directory

You may also want to compile on an older system such as Red Hat 9 or Debian 3.1 that uses an older version of glibc and RedHat

Best regards

Daniel


I will wake up this thread as I am currently in the step of X11 deployment.

Why do you suggest explicitally Red Hat 9 or Debian 3.1. Why not other brands or older one for Red Hat / Debian.

I suppose, that for Debian it was because the Sarge release 3.1 was still maintained when you post about it but now, support has finished for it.

For Red Hat 9, there is too no support and I don't think it was the case when you post about it.

But, as a good advice for other peoples, if you want to builf on a "Red Hat 9" like release, the best way is to use CentOS 3.X. This is the Red Hat Enterprise 3, based on Red Hat 9 and this one include security updates until 10/31/2010.

The only thing you have to do to properly compile Qt with the default settings is to use a fresher openssl library than the one bundled with CentOS 3, else compilation of Qt will failed.

You will have to use -I and -L flags for ./configure in order to give the correct location of libs and includes files from the fresher openssl, for example

./configure -I /usr/local/ssl/include -L /usr/local/ssl/lib


So I think a Red Hat Enterprise (or clone) is the best build platform for wide compatibility and its seven years support lifetime permit to use the older supported release to build Qt applications with an old glibc.

I've tried to build Qt on the older CentOS 2, still maintained too, but the Qt compilation has failed more seriously ;o)