2

I'm using folder structure like this:

program
program/app/app.py
program/app/lib.so
program/app/py_interfaces.so
program/launcher.py

I have compiled python interfaces py_interaces.so with boost.python linking to ./lib.so, so it would load library from the same folder as interfaces. I'm importing interfaces in app.py:

import py_interfaces

and if I run app.py it works fine. But I need to run from launcher/py and when I do that, I get error:

Import Error: ./lib.so: cannot open shared object file: no such file or directory.

I guess it loads py_interfaces.so fine, but it searches for lib.so in wrong folder: program. Would it be possible to force it to do it correctly? Should I link differently? I dont' want to change working directory (I need other files from root program directory)

Pawel
  • 169
  • 1
  • 12

1 Answers1

1

Are you sure . is the directory you're expecting? Note . means current working directory. launcher.py is not in the same directory as lib.so, and so that's what you're seeing. The way you linked things, you have to work in the app dir.

Try using real paths when linking or the path relative to the library, py_interfaces.so. This is something you need to fix in py_interfaces itself.

EDIT:

Here is a SO post about referencing a file relative to the executable/library path.

As mentioned by N.M. n the comments, the correct way to link with a relative path is to provide -rpath with $ORIGIN when linking, making the whole dependency thing more robust.

Community
  • 1
  • 1
kabanus
  • 24,623
  • 6
  • 41
  • 74
  • What I want is for `py_interfaces.so` to always look for `lib.so` in the same directory. And it works fine, excluding my scenario. – Pawel Apr 06 '17 at 12:23
  • Works fine you mean only when running from the same directory? – kabanus Apr 06 '17 at 12:29
  • Yes. But in my case I want `Launcher.py` to start `app/app.py` in another process. But then I think app.py imports `py_interfaces.so` "correctly", from `app` dir, but then interfaces search for `lib.so` in root folder. – Pawel Apr 06 '17 at 12:51
  • Indeed, you are correct. `./lib.so` means library will be looked for in current working directory, not "the same" directory as I thought. So it runs fine when working directory is script directory, but if it's not, problems occurs. The right way was provided by @n.m. - it it to use `-rpath` option with `$ORIGIN` setting. I tested it and it works I as wanted. Than you. Post it as an answer please so I can accept it. – Pawel Apr 06 '17 at 14:15
  • @Pawel thanks, I should write the answer explicitly - thanks and done. – kabanus Apr 06 '17 at 14:57