6

I know this question isn't very new but it seems as if I didn't be able to fix my problem on myself.

ldd generate the following output

u123@PC-Ubuntu:~$ ldd /home/u123/Programme/TestPr/Debug/TestPr
    linux-vdso.so.1 =>  (0x00007ffcb6d99000)
    libcsfml-window.so.2.2 => not found
    libcsfml-graphics.so.2.2 => not found
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcebb2ed000)
    /lib64/ld-linux-x86-64.so.2 (0x0000560c48984000)

Which is the correct way to tell ld the correct path?

|improve this question
  • You're asking the wrong question, imo. Use one of the existing paths that the linker knows about. See stackoverflow.com/a/10526145/350713. So, try running ldconfig -v 2>/dev/null | grep -v ^$'\t'. An obvious choice is /usr/local/lib if your linker knows about it. What is your distribution? And where are those libraries currently located? In any case, you should be able to install the binary packages you need to satisfy the linker. – Faheem Mitha Apr 27 '16 at 8:09
  • running the cmake for sfml has done the job – C-Jay Apr 28 '16 at 16:05
6

if your libraries are not on standard path then either you need to add them to the path or add non-standard path to LD_LIBRARY_PATH

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<Your_non-Standard_path>

Once you done any one of above things then you need to update the dynamic linker run-time binding by executing below command:

sudo ldconfig

UPDATE:

You can make the changes permanent by either writing the above export line into one of your startup files (e.g. ~/.bashrc) OR if the underlying library is not conflicting with any other library then put into one of standard library path (e.g. /lib,/usr/lib)

|improve this answer
  • 1
    thx, this works! But on the next time it is lost again. How could i set it permanent? – C-Jay Apr 27 '16 at 10:59
7

LD_LIBRARY_PATH is suitable for short tests, but since there is only one variable, it is awkward to use when you might have multiple applications with custom libraries.

The usual way for Debian/Ubuntu is to add it to the loader's configuration, e.g., a file under

/etc/ld.so.conf.d

containing the directory in which you want the loader to search, e.g.,

/usr/local/libcsfml

Further reading:

|improve this answer
  • This worked for me with the libnode.so library bundled with the electron framework, I was wondering whether this might lead to conflicts ? What if there is already a lib called libnode.so ? – MADforFUNandHappy Oct 17 '17 at 15:58
  • Technically different libraries with the same filename could have different soname values (in that case, ldconfig might accept both), but if they have the same soname and/or symbols, it won't be that cooperative. – Thomas Dickey Oct 17 '17 at 20:47
  • So should /etc/ld.so.conf.d be a text file with a list of absolute paths? – Petrus Theron Feb 12 at 14:13
  • no - it's a directory, under which there are files containing lists of absolute paths. – Thomas Dickey Feb 12 at 21:25
2

This looks as if the binary in question was compiled by you.

So you are responsible for the problem that some libraries cannot be found.

In case that these libraries are available on your system, they seem to be located in non-standard directory locations.

Use -R directory for the final compiler call to tell the linker the directory where the libraries are located. More than a single -R directory option is possible.

Note that when you are using gcc, you may need to use -Wl,-R instead of -R.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.