24

I am trying to build a c++ program using Unix.

I got the error

Linking CXX executable ../../bin/ME
/usr/bin/ld: cannot find -lboost_regex-mt

I heard that I just need to set the location of libboost* in my LD_LIBRARY_PATH env variable and then invoke make as I originally did, by typing

-L /usr/lib64 -l boost_regex-mt

or

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib64

But where is LD_LIBRARY_PATH? how do I set the LD_LIBRARY_PATH env variable?

  • Why did you edit out most of your question while it was providing some useful context to understand your issue? – jlliagre Nov 20 '14 at 19:49
  • @jlliagre I agree: without the context supplied by the original question, the top-voted answer makes no sense. I rolled it back. – John1024 Nov 15 '15 at 21:05
24

how do I set the LD_LIBRARY_PATH env variable?

You already set it when you did this:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib64

But that will not solve your problem. $LD_LIBRARY_PATH is consulted at time of execution, to provide a list of additional directories in which to search for dynamically linkable libraries. It is not consulted at link time (except maybe for locating libraries required by the built tools themselves!).

In order to tell the linker where to find libraries at build time, you need to use the -L linker option. You already did that too:

-L /usr/lib64

If you are still getting the error, then you need to make sure that the library is actually there. Do you have a file libboost_regex-mt.so or libboost_regex-mt.a in that (or any) directory? Note that a file like libboost_regex-mt.so.othersuffix doesn't count for this purpose. If you don't have that, then you probably need to install your distribution's development package for this library.

  • Under Linux, according to the ld(1) man page, $LD_LIBRARY_PATH is also consulted by ld: « 5. For a native linker, search the contents of the environment variable "LD_LIBRARY_PATH". » – vinc17 Nov 17 '14 at 1:05
  • @csx - what's your distro? Ubuntu, Fedora, CentOS, etc? See here, for eg: stackoverflow.com/questions/15874220/… – slm Nov 17 '14 at 3:22
  • @vinc17, That quote from the ld manpage only concerns recursive dependencies: dependent libraries of a library that was already selected to be linked in. It doesn't concern finding libraries for the executable being built. That's what -L does. – Celada Nov 17 '14 at 5:46
  • @csx I don't know anything about scientific linux, but if apt-get gives you command not found then it's not Debian derived so you need another method to install the missing package. That's definitely what your problem is though. – Celada Nov 17 '14 at 5:47
  • Late but: -Ldir -llib should work as arguments to ld or to gcc/g++/etc when including link phase, but original&restored Q mentions make: with a normal makefile you probably need LDFLAGS="whatever" and with a clever makefile you may need almost anything, including bricks to throw at the clever makefile author. – dave_thompson_085 Nov 15 '15 at 23:10
8

Another way to permanently add new path in LD_LIBRARY_PATH:

Edit .conf file in /etc/ld.so.conf.d/.

I have ever installed an application and its libraries couldn't be recognized by another application. Then I add the path, i.e /usr/local/hdf5/lib, to x86_64-linux-gnu.conf file. Just put in the next line. Save.

Then run sudo ldconfig

It worked.

PS: OS Ubuntu 14.04

2

If your library path error is in the linker, during compile, you need to add the path to the library into the variable $LD_LIBRARY_PATH. If the library error is when you actually run the compiled program then you need to add the library path to /etc/ld.so.conf and run ldconfig to rebuild the library search path cache.

  • this worked great! My conf file points to this directory /etc/ld.so.conf.d so just add a file with your libs path to that folder. also make sure to run ldconfig as root (or sudo it) – RLaaa May 5 '17 at 1:08
2

You can set it in your ~/.profile and/or specific init file of your shell (e.g. ~/.bashrc for bash, ~/.zshenv for zsh). Then you need to restart your shell (and possibly log out and log in again, depending on your choice).

You can check your settings with:

env | grep '^LD_LIBRARY_PATH'

EDIT: LD_LIBRARY_PATH is for shared libraries that contain machine code, whose filenames typically contain .so in their name, possibly followed by numbers separated by periods in order to distinguish different versions. It is possible that despite LD_LIBRARY_PATH, a library is not found because of ABI mismatch. Note also that languages (like Perl and Python) and packages may have their own system of libraries (possibly also with .so files), unrelated to LD_LIBRARY_PATH.

  • My compiled program still complains about not finding a python library although I see the correct path using env | grep '^LD_LIBRARY_PATH'. What could be the issue? – Herman Toothrot Mar 1 at 0:28
  • @HermanToothrot I've updated my answer. Note that python has its own system of libraries. I suspect that it does not use LD_LIBRARY_PATH (to avoid collisions with the usual libraries). You need to ask a specific question for this, with the error message you get. – vinc17 Mar 1 at 8:53

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.