MacOS X: dynamical libraries not found after installation of cuneiform 0.9.0

[Tobias Elze]

I'm trying to make a Portfile for cuneiform 0.9.0 on MacOS X. Therefore, I need to call make install with non standard prefixes. When I use such a non standard prefix, like this:

cmake -DCMAKE_BUILD_TYPE=debug -DCMAKE_INSTALL_PREFIX=/tmp/usr/ ..
make

everything compiles fine, and

./cuneiform
works:

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

However, after

make install

cuneiform is installed into the right directory according to the prefix, but the binary doesn't find it's own dynlibs anymore:

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

For cuneiform 0.8.0, everything works fine, no matter what prefix I give.

[Jussi Pakkanen (jpakkane)]

-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.

[Tobias Elze (macports)]

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

[Jussi Pakkanen (jpakkane)]

If you want to install stuff to nonstandard locations so that libraries are resolved automatically you need to set the runtime RPATH. CMake's docs tell you how to do it. It is not set by default, as this is a choice for the packager/distro. For example Debian forbids runtime RPATH except in certain specific circumstances.

[Tobias Elze (macports)]

Thanks, Jussi.

RPATH does not work on MacOS X. There's a special option just for Mac which plays the trick:

cmake -DCMAKE_INSTALL_NAME_DIR:STRING=${prefix}/lib [...]

solves the problem. I'll soon submit the Macports Portfile for cuneiform 0.9.0. Once it's accepted, maybe you want to inform users on the cuneiform webiste?

Best, Tobias.