[long post] Compiling gthumb with RAW support or why is it looking in all the wrong places

David Fox dfox94085 at gmail.com
Wed Mar 25 03:56:20 UTC 2009


2009/3/23 Felix 'buebo' Kakrow <spam at buebo.de>:

> So far so good, but when I try to start gthumb it errors out:
>
> mfk at sysiphus:~/src/gthumb-2.10.11$ gthumb
> gthumb: error while loading shared libraries: libgthumb.so: cannot open
> shared object file: No such file or directory

I expect that you are running the binary in /usr/bin, and not the
binary in /usr/local/bin. Assuming your path specifies /usr/local/bin,
does it come before the other ones, or after /usr/bin? That would
affect the outcome.

Sometimes bash doesn't always immediately notice that there is a new
binary in $PATH, and there should be a 'rehash' command that you can
run so that subsequent invocations of gthumb bring up the
locally-compiled version rather than the one that is 'stock' (i.e.,
/usr/bin).

You can get into trouble when you install versions of the same
software manually alongside stock versions of the software. But of
course, there are times when you need or want to do this (one example:
SVN ffmpeg vs "stock" ubuntu ffmpeg).

But I recommend against symlinking libraries across /usr/lib &
/usr/local/lib. That's guaranteed to cause breakage. There are two
versions of the libraries (in some cases, just adding extra features,
from one to the other, or the ABI is changed somewhere) and the result
is that the binary is expecting a particular symbol in the libraries
and is not able to find it. If you symlink, then /usr/bin/gthumb will
never work right, if at all, and the smarter choice would be to remove
gthumb via the package manager (assuming of course, that any
dependencies it relies on aren't broken, or important packages removed
when you do the package removal). Then if it is removed cleanly, then
you'll just be using your locally compiled version, but then you lose
any tracking for that package from the packaging system.

You might find that filing a wishlist bug against gthumb telling them
you want raw support is a better choice. I don't know the package well
enough and don't do much work with cameras (mostly I use digikam) so
am not sure if raw support requires libraries that aren't DFSG-free
(or the equivalent in Ubuntu)



-- 
thanks for letting me change the magnetic patterns on your hard disk.




More information about the ubuntu-users mailing list