17

I am trying to compile one of the projects found here USB-I2C/SPI/GPIO Interface Adapter.

I downloaded the i2c_bridge-0.0.1-rc2.tgz package. I installed libusb and that seemed to go well with no issues. I go into the i2c_bridge-0.0.1-rc2/ directory and make. That compiles. I move into the i2c_bridge-0.0.1-rc2/i2c folder and make. It compiles and gives me ./i2c. However, when I run it, it says error while loading shared libraries: libi2cbrdg.so: cannot open shared object file: No such file or directory

The makefile in i2c_bridge-0.0.1-rc2/i2c has the library directory as ../. The libi2cbrdg.so is in this directory (i2c_bridge-0.0.1-rc2). I also copied the file to /usr/local/lib. An ls of the i2c_bridge-0.0.1-rc2/ directory is

i2c        i2cbrdg.d  i2cbrdg.o  libi2cbrdg.a   Makefile  tests
i2cbrdg.c  i2cbrdg.h  INSTALL    libi2cbrdg.so  README    u2c4all.sh

(That i2c is a directory)

If I sudo ./i2c, it still gives me the problem.

I had to take away the -Werror and -noWdecrepated (spelling?) options in all the makefiles to get them to compile, but that shouldn't affect this should it?

What else is necessary for it to find the .so file? If anyone can help me find out what is wrong I would be very grateful. If more information is needed I can post it.

pizycki
  • 1,249
  • 4
  • 14
  • 26
Sterling
  • 3,835
  • 14
  • 48
  • 73
  • `cannot open shared object file` is sometime solved by issuing `sudo ldconfig` to refresh shared library cache of a previously compiled and installed package to make it ready for a compile of a downstream package – Scott Stensland Feb 06 '21 at 14:42

3 Answers3

41

You have to distinguish between finding so's at compile-time and at run-time. The -L flag you give at compile-time has nothing to do with localizing the library at run-time. This is rather done via a number of variables and some paths embedded in the library.

The best hot-fix for this problem is often setting LD_LIBRARY_PATH to the directory with the .so file, e.g.:

 $ LD_LIBRARY_PATH=.. ./i2c

For a long-term solution, you need to either have a close look at the whole LD system with rpath and runpath, or use libtool (which solves these issues for your portably).

Copying a file to /usr/local/lib is often insufficient because ld caches the available libraries, so you need to re-run ldconfig (as root) after you copied a library to /usr/local/lib.

Neuron
  • 5,141
  • 5
  • 38
  • 59
thiton
  • 35,651
  • 4
  • 70
  • 100
  • Is LD_LIBRARY_PATH for all of my libraries? So if I do that command, it will mess up other things until I change it back? How do I see what it is set to now? – Sterling Nov 07 '11 at 17:11
  • 2
    It's an environment variable. So you can check it via "echo $LD_LIBRARY_PATH" and, the way it is set in the command line, is local to the i2c process and its subprocesses. – thiton Nov 07 '11 at 17:34
  • 1
    Not my question, but thanks this helped solve my exact problem – Rich Jun 18 '12 at 16:41
25

If you are building the code from source that needs the the library, you can put the path that the library is in in the environment variable LD_RUN_PATH before building, and the linker will save that path into the binary, so that it will automatically be looked for in the right place at runtime.

Linux specific: Alternately, put the library in /lib, /usr/lib, or some other path referenced in your /etc/ld.so.conf or its imported config fragments, and then all you need to do is run /sbin/ldconfig to refresh ld.so (the dynamic linker)'s cache of libraries.

rakslice
  • 8,742
  • 4
  • 53
  • 57
  • Even though I had `/usr/local/lib` in `/etc/ld.so.conf.d/libc.conf`, the **dynamic link library cache refresh** with `sudo ldconfig` is what did it for me. – Serge Stroobandt Nov 18 '17 at 09:11
5

This works for my issue,hope will help anyone.

gcc test.c -Wl,-rpath /usr/local/lib -lfcgi -o test.fcg

And -Wl,-rpath option is the key trick.

pacholik
  • 8,607
  • 9
  • 43
  • 55
terwxqian
  • 591
  • 6
  • 7