13

I'm trying to compile a linux program, id3v2, and it says it is can't find the appropriate library: 

id3v2: error while loading shared libraries: libid3-3.8.so.3: cannot open shared object file: No such file or directory

I'm guessing that this is the part that pulls in the lidid3 library?

The file DOES exist, however, what they are looking for is actually a symbolic link to:

"ibid3-3.8.so.3.0.0"

I'm wondering if it is an issue with it not being able to follow symbolic links? Perhaps I could manually change it to look for 0.0 if I knew where I was looking to change it.

I'm happy to clarify any details.

It looks like the includes are done in the following manner: 

id3v2:  convert.o list.o id3v2.o genre.o
        ${CXX} ${LDFLAGS} -pedantic -Wall -g -o $@ $^ -lz -lid3

I was able to use Simon's advice to figure out that there were multiple spots where one might expect a library. I create a symbolic link where the program was linking to the ACTUAL file.

Thank you Simon!

Scott
  • 877
  • 4
  • 12
  • 24
  • 1
    Your title asks about the header, but your question's clearly about the shared library at runtime :-/. You might check if it works if you add the directory containing the symbolic link to your LD_LIBRARY_PATH environment variable. – Tony Delroy Jan 21 '11 at 01:47
  • I clearly don't understand what I'm doing. I will try to read your statement and see if I can follow your advice. – Scott Jan 21 '11 at 01:49
  • This might be promising... http://stackoverflow.com/questions/3490667/compiler-not-following-symbolic-links-in-visual-studio-c – Scott Jan 21 '11 at 01:50
  • 6
    Did you try running `ldconfig` as root? This program makes a registry of available libraries used for runtime library loading. The trick is that the library has to be in a place that `ldconfig` expects to see it, which depends on the distribution. The list of library directories is usually in `/etc/ld.so.conf` or somewhere similar. – Alex Jan 21 '11 at 01:53
  • I just ran ldconfig as root. No change. But now I know it exists! – Scott Jan 21 '11 at 03:00

3 Answers3

35

Symlinks on libraries work fine, as long as the final target they trace to exists and is accessible.

You have built a dynamically-linked executable, that wishes to be linked against libid3-3.8.so.3 at execution time. This was likely linked during the build phase with something like -L/path/to/libid3/directory -lid3.

You have a few options to make libid3 available, in generally decreasing order of preference (since you didn't mention where the file was, I can only be general):

  • Create a symlink to libid3* in a directory listed in /etc/ld.so.conf (or /lib or /usr/lib)
  • Copy libid3* to a directory listed in /etc/ld.so.conf (or /lib or /usr/lib) (defaults)
  • Add the directory containing libid3* to /etc/ld.so.conf
  • Set LD_LIBRARY_PATH=/directory/path/to/libid3* before running your id3v2 executable.
  • Recompile id3v2 statically. (It will work, but don't bother.)

After any of the first 3, rerun ldconfig so the linker cache is updated. (You can then run ldconfig -v to verify it's resolvable.)

Note those aren't steps, they're options. You only need to do 1 of them.

Glad you updated the title. #include directives have nothing to do with linking.

Sdaz MacSkibbons
  • 27,668
  • 7
  • 32
  • 34
  • Sorry about the directives, I have always "included" files in PHP, coldfusion and back with classic ASP. So, I figured "include" would mean that it was including something... – Scott Jan 21 '11 at 02:40
  • It is including something: the header, which contains the declarations of functions and variable types, etc., so that the compiler knows variable types, method signatures, etc. This is different from linking to a library, which provides access to concrete executable code either built into, or dynamically linked to the final executable. It can be confusing when going from an interpreted language, since there is less distinction (from the programmer's perspective, anyway) between source and executable code. – Sdaz MacSkibbons Jan 21 '11 at 02:43
  • Yeah, I have literally NEVER done anything with a compiled language. I'm sure I will reread everything you have written multiple times. Thanks again. – Scott Jan 21 '11 at 02:51
  • Do you have any idea of how I would figure out where it EXPECTS the file to be? – Scott Jan 21 '11 at 02:58
  • 1
    It can be in any of the directories listed in `/etc/ld.so.conf`, or the defaults of `/lib` and `/usr/lib`. The executable generally only has a library filename reference with no path. The runtime linker (usually `/lib/ld.so` or `/lib/ld-linux.so` with some version number in it) checks all of its configured directories for the library, and then links them in every time the program starts. If you just tell me the path where your `libid3-3.8.so.3` file is, I can give you exact commands. – Sdaz MacSkibbons Jan 21 '11 at 03:02
  • Hint: It might still be in the source directory for id3v2. – Sdaz MacSkibbons Jan 21 '11 at 03:07
  • ok. I can for sure tell you where the file I'm looking for is... "/usr/local/lib/libid-3.8.so.3.0.0" and "/usr/local/lib/libid-3.8.so.3" Linx says "libid3-3.8.so.3: symbolic link to `libid3-3.8.so.3.0.0'" – Scott Jan 21 '11 at 03:13
  • Ok. Just add `/usr/local/lib` to `/etc/ld.so.conf` (unless it's already in there; only put it once), then run `ldconfig`. This will be easiest. At that point, your `id3v2` program should be runnable. – Sdaz MacSkibbons Jan 21 '11 at 03:15
  • Going to try one more thing that makes sense to me and if/after that fails I will go after what you just suggested. It never crossed my mind that there might be more than one folder... – Scott Jan 21 '11 at 03:17
6

I got the same error you did, and after reading the solutions mentioned here, I resolved the problem (on Ubuntu 8) with:

sudo ln -s /usr/local/lib/libid3-3.8.so.3 /usr/lib/libid3-3.8.so.3
Mike Mackintosh
  • 13,917
  • 6
  • 60
  • 87
Kristopher Windsor
  • 221
  • 3
  • 7
2

This solved the issue just add /usr/local/lib to /etc/ld.so.conf (unless it's already in there; only put it once), then run ldconfig.

Guy Avraham
  • 3,482
  • 3
  • 38
  • 50
zombocom
  • 29
  • 4