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



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
    Commented Nov 20, 2014 at 19:49
  • 1
    @jlliagre I agree: without the context supplied by the original question, the top-voted answer makes no sense. I rolled it back.
    – John1024
    Commented Nov 15, 2015 at 21:05

5 Answers 5


how do I set the LD_LIBRARY_PATH env variable?

You already set it when you did this:


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
    Commented Nov 17, 2014 at 1:05
  • @csx - what's your distro? Ubuntu, Fedora, CentOS, etc? See here, for eg: stackoverflow.com/questions/15874220/…
    – slm
    Commented Nov 17, 2014 at 3:22
  • 1
    @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
    Commented Nov 17, 2014 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
    Commented Nov 17, 2014 at 5:47
  • 1
    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. Commented Nov 15, 2015 at 23:10

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


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? Commented Mar 1, 2019 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
    Commented Mar 1, 2019 at 8:53

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) Commented May 5, 2017 at 1:08

Solved with:

add into /etc/systemd/system/pm2-node.service

  • you must restart node app with update-env flag. 'pm2 start yourapp --update-env' Commented Jul 2, 2021 at 20:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .