can't find wordlist.db

[Matthias Andree]

Clint Adams <schizo at debian.org> writes:

>> Unfortunately, the GSL library hasn't changed version numbers although
>> the ABI has changed between 1.3 and 1.4 :-/
>
> I thought that there were only additions to the interface.

Doesn't help if we're using them, and we are.

If I bring a GSL-1.4 compiled bogofilter on a system with GSL-1.3, the
package manager will go "Hmm... let's look... we need libgsl.so.0. Oh,
it's there, fine, so let's just install the package." At run time, the
run-time linker will go "ho, the executable wants libgsl.so.0. Fine,
it's in /usr/lib, let's link it. Heck, it wants gsl_cdf_chisq_Q. Holy
shit, I've never seen that symbol. Let's better raise SIGKILL."

Boom, flaps shut, monkey dead, circus broke.

FreeBSD porters have figured as much, GSL 1.3 used to install as
libgsl.so.4, and GSL 1.4 installs libgsl.so.5 on FreeBSD, and old shared
libraries are usually (through portupgrade) kept in
/usr/local/lib/compat/pkg/ when the library is updated so applications
need not be relinked immediately and continue to work.

 Of course, this is unfortunate, because the GSL major version differs
from FreeBSD to other systems, but at least, there are no surprises of
the "linker symbol gsl_cdf_chisq_Q not found" kind - the package manager
will figure "libgsl.so.5 missing, so let's fetch and build /that/ first".

Some dynamic linkers are smart enough to take that library version with
matching major and highest minor number in the corresponding directory,
and will link against libexample.so.1.5 when libexample.so.1.4 was
requested - but this won't work across directories, and on some system,
an /usr/lib/libexample.so.1.4 shadows an
/usr/local/lib/libexample.so.1.5 so an application requesting
libexample.so.1.5 will die.

The whole concept of binary portability on Linux doesn't work, every
packager has his own package names, -dev/-devel split from main package
(if any) and so on.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95