On Fri, Aug 19, 2005 at 10:08:47PM -0500, Ralph Mitchell wrote:
> Is that a reasonable expectation?? Compiling and dynamically linking
> something on one distribution and expecting it to run on a different
> distribution?? I wouldn't think so. I'm not an expert, but I wouldn't try
> it or expect it to work as advertised...

You are right, the differences between distros often make packages for
several distros (e.g. one RPM for both Redhat and SUSE) difficult or
impossible.

However, this has long been regarded as a Bad Thing by a lot of people - as
a result, there have been efforts to remove incompatibilities. These
efforts include the LSB (Linux Standard Base), work on GCC to ensure better
compatibility between code compiled by different versions, Debian Common
Core etc... These days, if you're careful and a little lucky, it certainly
*is* possible to build binaries which run on a number of different Linux
distros.

However, it can be a big problem if different distros compile libraries in
different ways. For example, if the library's API changes in response to a
configure switch (say, some functions are not available unless you enable a
feature), this will break cross-distro compatibility.

So my advice to upstream authors is to _always_ "mandate" the following:
 - an identical set of symbols offered by the lib
 - an identical number of libraries
 - identical library names
...and all this independent of what features the library was compiled with.

Example: Even if the library was compiled --without-ssl, a (hypothetical)
function "use_ssl()" should still be available, and it should flag an error
in an appropriate way when called.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer     |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯