Comment 2 for bug 566828

Hi Jussi,

first of all, thanks for the very quick reply.

> -DCMAKE_INSTALL_PREFIX is supposed to be the final installation
> directory. Not /tmp/whatever. You need to pass the temporary install
> prefix to make install with DESTDIR=/tmp/whatever. Or something like
> that, I don't remember ATM. See CMake's docs.

So do you mean, $PREFIX/lib must be in your library path or otherwise added manually? That will work, for sure: If I add $PREFIX/lib to DYLD_LIBRARY_PATH (MacOS X) or to LD_LIBRARY_PATH (Linux), everything works fine.

However, allow me a short statement why this is not a good behavior. Please don't misunderstand this as nagging, I'm glad that you invest your time and work into cuneiform and I'm grateful to use it as free and open source software. So please read this as a constructive criticism.

"make" is supposed to create a local binary in the source directory. This binary includes all the necessary information about where to find it's dynamical libraries. That works fine with cuneiform 0.8.0 and 0.9.0 equally. According to Unix conventions, "make install" then not only copies the libs to $PREFIX/lib and the binaries to $PREFIX/bin but also ensures that the dynamical libs are found under the new location $PREFIX/lib by the binary.

cuneiform 0.8.0 obeys to these conventions:

cmake -DCMAKE_BUILD_TYPE=debug -DCMAKE_INSTALL_PREFIX=/my/cuneiform08 ..
make
./cuneiform

Cuneiform for Linux 0.8.0
Usage: ./cuneiform[-l languagename -f format --dotmatrix --fax -o result_file] imagefile

make install
/my/cuneiform08/bin/cuneiform

Cuneiform for Linux 0.8.0
Usage: ./cuneiform[-l languagename -f format --dotmatrix --fax -o result_file] imagefile

That's fine. However, cuneiform 0.9.0 unfortunately abandons this convenient and conventional behavior:

cmake -DCMAKE_BUILD_TYPE=debug -DCMAKE_INSTALL_PREFIX=/my/cuneiform09 ..
make
./cuneiform

Cuneiform for Linux 0.9.0
Usage: ./cuneiform [-l languagename -f format --dotmatrix --fax -o result_file] imagefile

make install
/my/cuneiform09/bin/cuneiform

dyld: Library not loaded: libcuneiform.0.9.0.dylib
  Referenced from: /tmp/usr/bin/cuneiform
  Reason: image not found
Trace/BPT trap

Even if you don't consider this a bug, why is this at least undesirable? It's true: If one uses the standard prefix, this will in most cases work, as then $PREFIX/lib is in the library path. However, imagine someone wants to install to /usr/local instead, or into the local home directory? I don't think common ubuntu users, for instance, will have any of this in their library path and might be quite confused by the message shown above.

Moreover, concepts like Macports which rely on standard GNU conventions are faced with enormous difficulties with such a behavior as in 0.9.0 (the standard prefix of Macports is definitely not in the lib path), not to mention more exotic Unix systems with quite non-standard packaging systems.

I would therefore suggest to retain the behavior of version 0.8.0 in future versions of cuneiform. You will save users who need to compile themselves or packagers a lot of painstaking work.

Best,

Tobias