./pdffigures/pdffigures: /usr/lib/x86_64-linux-gnu/libstdc++.so.6:version `GLIBCXX_3.4.20' not found

./pdffigures/pdffigures: /usr/lib/x86_64-linux-gnu/libstdc++.so.6:version `GLIBCXX_3.4.20' not found

https://developer.ibm.com/answers/questions/184266/libstdcso6-version-glibcxx-3420-not-found.html

Hi< Sounds like linker issue, Please suggestions made in

https://gcc.gnu.org/onlinedocs/libstdc++/faq.html

3.4.

How do I insure that the dynamically linked library will be found?

Depending on your platform and library version, the error message might be similar to one of the following:

 
 
 ./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
 /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found
 

This doesn't mean that the shared library isn't installed, only that the dynamic linker can't find it. When a dynamically-linked executable is run the linker finds and loads the required shared libraries by searching a pre-configured list of directories. If the directory where you've installed libstdc++ is not in this list then the libraries won't be found.

If you already have an older version of libstdc++ installed then the error might look like one of the following instead:

 
 
 ./a.out: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found
 ./a.out: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.8' not found
 

This means the linker found /usr/lib/libstdc++.so.6 but that library belongs to an older version of GCC than was used to compile and link the program a.out (or some part of it). The program depends on code defined in the newer libstdc++ that belongs to the newer version of GCC, so the linker must be told how to find the newer libstdc++ shared 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:

 
 
 export LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH
 

Here the shell variable ${prefix} is assumed to contain the directory prefix where GCC was installed to. The directory containing the library might depend on whether you want the 32-bit or 64-bit copy of the library, so for example would be ${prefix}/lib64 on some systems. The exact environment variable to use will depend on your platform, e.g. DYLD_LIBRARY_PATH for Darwin, LD_LIBRARY_PATH_32/LD_LIBRARY_PATH_64 for Solaris 32-/64-bit, and SHLIB_PATH for HP-UX.

See the man pages for ld, ldd and ldconfig for more information. The dynamic linker has different names on different platforms but the man page is usually called something such as ld.so, rtld or dld.so.

Using LD_LIBRARY_PATH is not always the best solution, Finding Dynamic or Shared Libraries in the manual gives some alternatives.

prefix ,I use in ubuntu64 , /usr/local/lib64/, success