Bug #2535

i686: krita fails to start because it's linked to instead of

GNUtoo - about 4 years ago - . Updated over 3 years ago.

% Done:



On i686 krita fails to start while it does start on x86_64:

$ krita
krita: error while loading shared libraries: cannot open shared object file: No such file or directory

This is because it links to (

$ ldd $(which krita) | grep libHalf => not found => not found => not found => not found

Whereas on x86_64 (where krita works) we have:

$ ldd $(which krita) | grep libHalf => /usr/lib/ (0x00007f4ea8168000)



Updated by freemor about 4 years ago

Krita is an [extra] package can the OP check if this issue still exists. If so I'll forward upstream.


Updated by bill-auger about 4 years ago is in libre/openexr - that crazy .so name change is
something the upstream did recently

$ pkgfile

$ pkgfile -l openexr | grep libHalf
libre/openexr /usr/lib/
libre/openexr /usr/lib/
libre/openexr /usr/lib/
libre/openexr /usr/lib/

i think what happened was that oaken-source upgraded openexr for x86_64 and also i686, but that pushed i686 ahead of arch32, where krita was still expecting the original naming scheme - its just so tempting to try rolling all three ports at the same spped due to the convenience; but that often causes problems, and is why some tickets stay open for a very long time


Updated by GNUtoo over 3 years ago

  • Status changed from unconfirmed to confirmed

Updated by GNUtoo over 3 years ago

  • Assignee set to GNUtoo

Updated by GNUtoo over 3 years ago

  • Status changed from confirmed to fixed

fixed, we don't have the issue anymore as krita starts fine.

Also available in: Atom PDF