ImportError: libmypaint-1.3.so.0: can not open shared object file: No such file or directory

[Itzcuauhtli]

Hello, I come to you with the following problem. Normally I use MyPaint compiled from git and normally I don't have a problem, but this time I can't resolve it. My problem then begins I reinstall Ubuntu 16.04 LTS in my laptop (an Asus S-300c) with Unity. I compile from both libmypaint and mypaint. In the case of libmypaint I follow the webpage's instructions

$./autogen.sh
$ ./configure
$ sudo make install

In the case of MyPaint I install from the next form:

$ git clone https://github.com/mypaint/mypaint.git
$ cd mypaint
$ git pull
$ git submodule update --init --force
$ scons
$ sudo scons prefix=/usr/local install
$ sudo mypaint

But in this last step, terminal give me the next message

INFO: mypaint: Installation layout: conventional POSIX-like structure with prefix u'/usr/local'
INFO: lib.i18n: POSIX: LANG='es_MX.UTF-8'
INFO: lib.i18n: POSIX: LANGUAGE='es_MX:es'
Traceback (most recent call last):
File "/usr/local/bin/mypaint", line 462, in
main.main(datapath, iconspath, old_confpath, version=version)
File "/usr/local/share/mypaint/gui/main.py", line 96, in main
from gui import application
File "/usr/local/share/mypaint/gui/application.py", line 49, in
import lib.document
File "/usr/local/share/mypaint/lib/document.py", line 37, in
import lib.helpers as helpers
File "/usr/local/share/mypaint/lib/helpers.py", line 26, in
import mypaintlib
File "/usr/local/share/mypaint/lib/mypaintlib.py", line 28, in
_mypaintlib = swig_import_helper()
File "/usr/local/share/mypaint/lib/mypaintlib.py", line 20, in swig_import_helper
import _mypaintlib
ImportError: libmypaint-1.3.so.0: can not open shared object file: No such file or directory

(originally, in spanish:
ImportError: libmypaint-1.3.so.0: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio
)

So. I missing something or I'm missing something?

Thanks for reading me :)

[achadwick]

Please don't run MyPaint as root (do not run it with sudo as above). It will write files which you will not be able to overwrite or delete.

Do not run commands with sudo unless you know what you are doing.

---

Please use Github's "code fencing" feature for log output or code. Like this:

```
log lines
go here
```

If you don't, github sometimes tries to be too smart about references to other bugs, and will make an association when it shouldn't.

More information here: https://guides.github.com/features/mastering-markdown/#examples (under "Code")

[achadwick]

Hi there - thanks for the feedback!

This issue tracker is not for direct user support really. We try to limit it so that each thread is a single fixable issue which can be closed by changing the MyPaint code. I won't close this report straight away though because sometimes we can help. Often the feedback is useful too, and sometimes support requests can turn into stuff programmers can actually do something about!

We may not be able to help you straight away here, but don't be discouraged if we can't. Issue trackers don't get that many views, sadly. You may find you get more useful feedback from the MyPaint Community Forums.

[achadwick]

First, lets be sure it's a real bug.

Do a fresh clone of both mypaint and libmypaint, and reinstall them using the instruction on these pages:

• https://github.com/mypaint/libmypaint/blob/master/README.md
• https://github.com/mypaint/mypaint/blob/master/README_LINUX.md [EDIT: correct the link 😳]

You don't need the line about submodules, and you don't need to run anything with sudo except for the final "install" commands.

After you have installed libmypaint, please do the following, and paste the output here between backtick lines:

pkg-config --libs libmypaint
pkg-config --cflags libmypaint
ls -ld /usr/lib/*mypaint* /usr/local/lib/*mypaint*

[EDIT: oops, pasted a bit too much. That's three lines...]
The output should look like this:

$ pkg-config --libs libmypaint
-lmypaint -ljson-c -lgobject-2.0 -lglib-2.0
$ pkg-config --cflags libmypaint
-I/usr/include/json-c -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libmypaint
$ ls -ld /usr/lib/*mypaint* /usr/local/lib/*mypaint*
ls: cannot access '/usr/local/lib/*mypaint*': No such file or directory
lrwxrwxrwx 1 root root    23 Jun  6 23:48 /usr/lib/libmypaint-1.3.so.0 -> libmypaint-1.3.so.0.0.0
-rw-r--r-- 1 root root 74952 Jun  6 23:48 /usr/lib/libmypaint-1.3.so.0.0.0
lrwxrwxrwx 1 root root    23 Jun  6 23:48 /usr/lib/libmypaint.so -> libmypaint-1.3.so.0.0.0
drwxr-xr-x 2 root root  4096 May 30 16:09 /usr/lib/mypaint

[danpla]

Have you tried sudo ldconfig?

[achadwick]

@Itzcuauhtli any luck trying the suggestions above?

[mistycheney]

I had the same problem, but running sudo ldconfig fixes the error.

[achadwick]

@Itzcuauhtli Please respond. If we get no response, this issue is just clutter in our issue tracker. Did running sudo ldconfig on your Ubuntu system fix this problem?

---

Why sudo for ldconfig

ldconfig is a program which updates your computer's idea of what libs it has installed by rewriting links with versions in their filenames. Normally this step is handled automatically by operating system packages or application bundles. If you are doing it manually, you need sudo for this step because the links are contained in a protected area.

ldconfig is not part of MyPaint. It is a low-level program that can be found on any Linux system.

ldconfig is not needed for Windows computers. Those use a different way of locating library files.

Fixing a root-owned MyPaint configuration (accidental "sudo")

Using sudo for arbitrary things because they don't work at first could eventually break your Ubuntu install. You may already have broken your MyPaint configuration. You should be able to fix that and other things which are going wrong with:

$ sudo chown --changes --recursive "$USER" "$HOME"

This chown command line changes the ownership of all files within your home folder, including any root-owned files which the MyPaint you ran as root may have written. It changes them to be owned by you once again. It will tell you about the changes it makes, so the output can be blank. Sudo is needed for this command because the underlying chown() system call is not allowed to make file ownership changes without special privileges.

The system administrator in me is reminding me: unmount any drive mounts under your home first. I think Ubuntu and other systemd systems place flash drives and other things under /media these days, so you should be safe. But check what df -h | fgrep "$HOME" or mount | fgrep "$HOME" say first (they should say nothing).

[achadwick]

TRIAGE NOTE: looks like a user support request. Normally we direct these to the community forums, but there were issues with sudo which it is good to document.

Works for everyone else, so this issue should be closed after one week if no further information is forthcoming that would allow it to be progressed to bug or enhancement status.

[achadwick]

Closing this old, stale issue.