91

It turns out that "make install" - the make target that installs and implies the target "install-target-libstdc++v3" doesn't actually mean you're ready to go.

I've been stuck for a while wondering what I was doing wrong because I assumed that such a make target would do that for me.

E_net4
  • 27,810
  • 13
  • 101
  • 139
Alec Teal
  • 5,770
  • 3
  • 23
  • 50
  • sudo apt-get install gcc-4.9 – Yuliia Ashomok Jun 17 '16 at 06:04
  • 2
    If you are the programer that compiler the the program, you can add `-static` to the gcc command line to static link your program. see: https://stackoverflow.com/questions/13636513/linking-libstdc-statically-any-gotchas – bronze man Oct 10 '18 at 07:53
  • 33
    I vote to reopen: this is the top google result for this error message, so having the answers frozen is a real disadvantage. – Owen Apr 24 '19 at 04:44
  • @Owen it's actually been closed several times - IIRC this was my third posting (seriously) - however the error and the "fix" on this page are not really properly dealt with here. Just a specific case yielding the error. – Alec Teal Apr 25 '19 at 09:00

8 Answers8

68

Add the library's path to the LD_LIBRARY_PATH environment variable

TL;DR

GCC requires you to tell it where your library is located manually when it can't find the right version, which can be done in a few ways. One is adding it to the LD_LIBRARY_PATH.

export LD_LIBRARY_PATH="/usr/local/lib64/:$LD_LIBRARY_PATH"

For some, the library path will be /usr/local/lib64/. Others have reported the library path /usr/lib/x86_64-linux-gnu/ working for them instead.

Why do we need to add the library to LD_LIBRARY_PATH?

When you compile and install GCC it puts the libraries in one of these directories, but that's all it does. According to the FAQs for libstdc++, the error that we got means that the dynamic linker found the wrong version of the libstdc++ shared library. Because the linker can't find the right version, we have to tell it where to find the libstdc++ library.

The simplest way to fix this is to use the LD_LIBRARY_PATH environment variable, which is a colon-separated list of directories in which the linker will search for shared libraries.

There are other ways as well to fix this issue. You can find this and the other solutions mentioned briefly when you install gcc if you read the make output:

Libraries have been installed in:

/usr/local/lib/../lib32

If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following:

  • add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution
  • add LIBDIR to the `LD_RUN_PATH' environment variable during linking
  • use the `-Wl,-rpath -Wl,LIBDIR' linker flag
  • have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages.

Grr, that was simple! Also, "if you ever happen to want to link against the installed libraries," seriously?

Andria
  • 4,712
  • 2
  • 22
  • 38
Alec Teal
  • 5,770
  • 3
  • 23
  • 50
  • 3
    You generally *don't* want to link against random versions of libraries that you just installed. Your software will not run on any other machine. It is usually better to use the older versions of the libraries that are included with your operating system. If you do need to build libraries then you'll have to include all of them when distributing your software. And if your software is another library which is linked to yet another library which is using a third version of libstdc++ then your program is just not going to work. – Zan Lynx Dec 03 '13 at 17:00
  • 1
    @ZanLynx isn't that the point of the .x.y.z we have? So it's not random? I suppose not everything specifies a version (hence the default symlink) right? – Alec Teal Dec 03 '13 at 17:10
  • What if the directory /usr/local/lib64 does not exist? I do have libstdc++6 and gcc 4.8 installed. – cxrodgers Jan 03 '15 at 00:21
  • @cxrodgers then just lib, I assumed you'd have a 64bit system – Alec Teal Jan 03 '15 at 01:27
  • I do have a 64-bit system. I get the same error no matter whether I add /usr/local/lib or /usr/local/lib64 (which doesn't even exist) to my path. The library appears to be located at /usr/lib/x86_64-linux-gnu/libstdc++.so.6 but it doesn't help to add this to the path either. Perhaps this needs to be its own question. – cxrodgers Jan 03 '15 at 06:26
  • @cxrodgers then you need to post a question yes – Alec Teal Jan 03 '15 at 13:31
  • 2
    @AlecTeal The problem is that you don't want *every program* to link against the new lib *at run time*, which is what LD_LIBRARY_PATH does. See http://xahlee.info/UnixResource_dir/_/ldpath.html – Britton Kerin Aug 26 '17 at 13:19
  • this work for me. conda install -c anaconda tensorflow – Humayoo Mar 15 '18 at 02:34
  • @AlecTeal Kind of worked but I don't have that `/usr/local/lib64`, only `/usr/local/lib` so my program is throwing another error – o0ragman0o May 10 '18 at 03:43
  • @o0ragman0o are you working with GCC too? Or are you here for the same problem in a different area? I found this in GCC's output (scroll up a bit when it's done) - see hat yours says. – Alec Teal May 11 '18 at 04:09
  • @AlecTeal ran into it after trying to update an application which turns out to have been compiled in 4.9. I was still on Mint 17 (ubuntu14.04) which has 4.8. Have ended up doing a full upgrade to Mint 18.3 rather than manhandle library paths and such – o0ragman0o May 17 '18 at 09:50
  • I don't think that `/usr/lib/x86_64-linux-gnu/` needs to be its own question. It's just another location and it works just fine, it sounds like @cxrodgers was just accidentally putting the file and not the directory in the path. The following works for me: `export LD_LIBRARY_PATH="/usr/lib/x86_64-linux-gnu/"`. – Andria Aug 22 '21 at 02:40
  • Thanks. I had this error when trying to make mysql-8 from source. – le hien Sep 21 '22 at 07:19
24

I had the same problem on my Ubuntu 14.04 when tried to install TopTracker. I got such errors:

/usr/share/toptracker/bin/TopTracker: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'CXXABI_1.3.8' not found (required by /usr/share/toptracker/bin/TopTracker) /usr/share/toptracker/bin/TopTracker: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'GLIBCXX_3.4.21' not found (required by /usr/share/toptracker/bin/TopTracker) /usr/share/toptracker/bin/TopTracker: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'CXXABI_1.3.9' not found (required by /usr/share/toptracker/bin/TopTracker)

But I then installed gcc 4.9 version and problem gone:

sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.9 g++-4.9
Footniko
  • 2,682
  • 2
  • 27
  • 36
10

I've got correct solution here.

The best way to correctly install gcc-4.9 and set it as your default gcc version use:

sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.9 g++-4.9
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.9

The --slave, with g++, will cause g++ to be switched along with gcc, to the same version. But, at this point gcc-4.9 will be your only version configured in update-alternatives, so add 4.8 to update-alternatives, so there actually is an alternative, by using:

sudo apt-get install gcc-4.8 g++-4.8
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.8

Then you can check which one that is set, and change back and forth using:

sudo update-alternatives --config gcc

NOTE: You could skip installing the PPA Repository and just use /usr/bin/gcc-4.9-base but I prefer using the fresh updated toolchains.

Community
  • 1
  • 1
Yuliia Ashomok
  • 8,336
  • 2
  • 60
  • 69
4

In my case it was gcc 6 the one missing

sudo apt-get install gcc-6 g++-6 -y

Update

sudo apt-get install gcc-7 g++-7 -y
Jose Ospina
  • 2,097
  • 3
  • 26
  • 40
3

This solution work on my case i am using ubuntu 16.04, VirtualBox 2.7.2 and genymotion 2.7.2 Same error come in my system i have followed simple step and my problem was solve 

1. $ LD_LIBRARY_PATH=/usr/local/lib64/:$LD_LIBRARY_PATH
2. $ export LD_LIBRARY_PATH
3. $ sudo apt-add-repository ppa:ubuntu-toolchain-r/test
4. $ sudo apt-get update
5. $ sudo apt-get install gcc-4.9 g++-4.9

I hope this will work for you

Vipin Jain
  • 3,686
  • 16
  • 35
2

What the other answers suggest will work for the program in question, but it has the potential to cause breakage in other programs and unknown dependence elsewhere. It's better to make a tiny wrapper script:

#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH
program_needing_different_run_time_library_path

This mostly avoids the problem described in Why LD_LIBRARY_PATH is bad by confining the effects to the program which needs them.

Note that despite the names LD_RUN_PATH works at link-time and is non-evil, while LD_LIBRARY_PATH works at both link and run time (and is evil :).

Britton Kerin
  • 427
  • 4
  • 9
1

I ran into this issue on my Ubuntu-64 system when attempting to import fst within python as such:

    Python 3.4.3 |Continuum Analytics, Inc.| (default, Jun  4 2015, 15:29:08)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import fst
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ogi/miniconda3/lib/python3.4/site-packages/pyfst-0.2.3.dev0-py3.4-linux-x86_64.egg/fst/__init__.py", line 1, in <module>
    from fst._fst import EPSILON, EPSILON_ID, SymbolTable,\
ImportError: /home/ogi/miniconda3/lib/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/local/lib/libfst.so.1)

I then ran:

ogi@ubuntu:~/miniconda3/lib$ find ~/ -name "libstdc++.so.6"
/home/ogi/miniconda3/lib/libstdc++.so.6
/home/ogi/miniconda3/pkgs/libgcc-5-5.2.0-2/lib/libstdc++.so.6
/home/ogi/miniconda3/pkgs/libgcc-4.8.5-1/lib/libstdc++.so.6
find: `/home/ogi/.local/share/jupyter/runtime': Permission denied
ogi@ubuntu:~/miniconda3/lib$

mv /home/ogi/miniconda3/lib/libstdc++.so.6 /home/ogi/miniconda3/libstdc++.so.6.old
cp /home/ogi/miniconda3/libgcc-5-5.2.0-2/lib/libstdc++.so.6 /home/ogi/miniconda3/lib/

At which point I was then able to load the library

ogi@ubuntu:~/miniconda3/lib$ python
Python 3.4.3 |Continuum Analytics, Inc.| (default, Jun  4 2015, 15:29:08)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import fst
>>> exit()
Ogi Moore
  • 131
  • 9
1

Had the same error when installing PhantomJS on Ubuntu 14.04 64bit with gcc-4.8 (CXXABI_1.3.7)

Upgrading to gcc-4.9 (CXXABI_1.3.8) fixed the issue. HOWTO: https://askubuntu.com/questions/466651/how-do-i-use-the-latest-gcc-4-9-on-ubuntu-14-04

Community
  • 1
  • 1
Marek Tichy
  • 59
  • 3