/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.8' not found [closed]












55















I recently asked for help https://stackoverflow.com/questions/20253515/no-idea-as-to-usr-lib-x86-64-linux-gnu-libstdc-so-6-version-cxxabi-1-3-8 and it got downvoted and closed (I don't know why)



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.



I hope this answer helps at least one other person.










share|improve this question















closed as off-topic by E_net4, Toby Speight, jww, Makyen, Pearly Spencer Nov 24 '18 at 14:20


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – E_net4, Toby Speight, Pearly Spencer

If this question can be reworded to fit the rules in the help center, please edit the question.

















  • sudo apt-get install gcc-4.9

    – Yuliia Ashomok
    Jun 17 '16 at 6:04











  • 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: stackoverflow.com/questions/13636513/…

    – bronze man
    Oct 10 '18 at 7:53
















55















I recently asked for help https://stackoverflow.com/questions/20253515/no-idea-as-to-usr-lib-x86-64-linux-gnu-libstdc-so-6-version-cxxabi-1-3-8 and it got downvoted and closed (I don't know why)



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.



I hope this answer helps at least one other person.










share|improve this question















closed as off-topic by E_net4, Toby Speight, jww, Makyen, Pearly Spencer Nov 24 '18 at 14:20


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – E_net4, Toby Speight, Pearly Spencer

If this question can be reworded to fit the rules in the help center, please edit the question.

















  • sudo apt-get install gcc-4.9

    – Yuliia Ashomok
    Jun 17 '16 at 6:04











  • 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: stackoverflow.com/questions/13636513/…

    – bronze man
    Oct 10 '18 at 7:53














55












55








55


14






I recently asked for help https://stackoverflow.com/questions/20253515/no-idea-as-to-usr-lib-x86-64-linux-gnu-libstdc-so-6-version-cxxabi-1-3-8 and it got downvoted and closed (I don't know why)



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.



I hope this answer helps at least one other person.










share|improve this question
















I recently asked for help https://stackoverflow.com/questions/20253515/no-idea-as-to-usr-lib-x86-64-linux-gnu-libstdc-so-6-version-cxxabi-1-3-8 and it got downvoted and closed (I don't know why)



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.



I hope this answer helps at least one other person.







c++ linux unix






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 23 '18 at 17:35









jww

53.3k40230504




53.3k40230504










asked Dec 3 '13 at 16:52









Alec TealAlec Teal

3,77411339




3,77411339




closed as off-topic by E_net4, Toby Speight, jww, Makyen, Pearly Spencer Nov 24 '18 at 14:20


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – E_net4, Toby Speight, Pearly Spencer

If this question can be reworded to fit the rules in the help center, please edit the question.







closed as off-topic by E_net4, Toby Speight, jww, Makyen, Pearly Spencer Nov 24 '18 at 14:20


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – E_net4, Toby Speight, Pearly Spencer

If this question can be reworded to fit the rules in the help center, please edit the question.













  • sudo apt-get install gcc-4.9

    – Yuliia Ashomok
    Jun 17 '16 at 6:04











  • 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: stackoverflow.com/questions/13636513/…

    – bronze man
    Oct 10 '18 at 7:53



















  • sudo apt-get install gcc-4.9

    – Yuliia Ashomok
    Jun 17 '16 at 6:04











  • 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: stackoverflow.com/questions/13636513/…

    – bronze man
    Oct 10 '18 at 7:53

















sudo apt-get install gcc-4.9

– Yuliia Ashomok
Jun 17 '16 at 6:04





sudo apt-get install gcc-4.9

– Yuliia Ashomok
Jun 17 '16 at 6:04













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: stackoverflow.com/questions/13636513/…

– bronze man
Oct 10 '18 at 7:53





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: stackoverflow.com/questions/13636513/…

– bronze man
Oct 10 '18 at 7:53












8 Answers
8






active

oldest

votes


















35














For all those stuck with a similar problem, run the following:



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


When you compile and install GCC it does put the libraries here but that's it. As the FAQs say ( http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths ) you need to add it.



I assumed "How do I insure that the dynamically linked library will be found? " meant "how do I make sure it is always found" not "it wont be found, you need to do this"



For those who don't bother setting a prefix, it is /usr/local/lib64



You can find this 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?






share|improve this answer



















  • 2





    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 3 '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 3 '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 3 '15 at 0:21











  • @cxrodgers then just lib, I assumed you'd have a 64bit system

    – Alec Teal
    Jan 3 '15 at 1:27






  • 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 xahlee.info/UnixResource_dir/_/ldpath.html

    – Britton Kerin
    Aug 26 '17 at 13:19



















18














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





share|improve this answer































    6














    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.






    share|improve this answer





















    • 2





      Doesn't work. Still gives the same error.

      – Akshay Hazari
      Jul 31 '17 at 8:51











    • what if I don't have sudo access? then how can implement your approach?

      – Rishabh Agrahari
      Dec 10 '18 at 20:08



















    2














    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






    share|improve this answer































      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






      share|improve this answer

































        0














        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()





        share|improve this answer































          0














          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 :).






          share|improve this answer































            0














            In my case it was gcc 6 the one missing




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






            share|improve this answer
































              8 Answers
              8






              active

              oldest

              votes








              8 Answers
              8






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              35














              For all those stuck with a similar problem, run the following:



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


              When you compile and install GCC it does put the libraries here but that's it. As the FAQs say ( http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths ) you need to add it.



              I assumed "How do I insure that the dynamically linked library will be found? " meant "how do I make sure it is always found" not "it wont be found, you need to do this"



              For those who don't bother setting a prefix, it is /usr/local/lib64



              You can find this 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?






              share|improve this answer



















              • 2





                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 3 '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 3 '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 3 '15 at 0:21











              • @cxrodgers then just lib, I assumed you'd have a 64bit system

                – Alec Teal
                Jan 3 '15 at 1:27






              • 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 xahlee.info/UnixResource_dir/_/ldpath.html

                – Britton Kerin
                Aug 26 '17 at 13:19
















              35














              For all those stuck with a similar problem, run the following:



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


              When you compile and install GCC it does put the libraries here but that's it. As the FAQs say ( http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths ) you need to add it.



              I assumed "How do I insure that the dynamically linked library will be found? " meant "how do I make sure it is always found" not "it wont be found, you need to do this"



              For those who don't bother setting a prefix, it is /usr/local/lib64



              You can find this 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?






              share|improve this answer



















              • 2





                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 3 '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 3 '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 3 '15 at 0:21











              • @cxrodgers then just lib, I assumed you'd have a 64bit system

                – Alec Teal
                Jan 3 '15 at 1:27






              • 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 xahlee.info/UnixResource_dir/_/ldpath.html

                – Britton Kerin
                Aug 26 '17 at 13:19














              35












              35








              35







              For all those stuck with a similar problem, run the following:



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


              When you compile and install GCC it does put the libraries here but that's it. As the FAQs say ( http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths ) you need to add it.



              I assumed "How do I insure that the dynamically linked library will be found? " meant "how do I make sure it is always found" not "it wont be found, you need to do this"



              For those who don't bother setting a prefix, it is /usr/local/lib64



              You can find this 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?






              share|improve this answer













              For all those stuck with a similar problem, run the following:



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


              When you compile and install GCC it does put the libraries here but that's it. As the FAQs say ( http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths ) you need to add it.



              I assumed "How do I insure that the dynamically linked library will be found? " meant "how do I make sure it is always found" not "it wont be found, you need to do this"



              For those who don't bother setting a prefix, it is /usr/local/lib64



              You can find this 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?







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Dec 3 '13 at 16:52









              Alec TealAlec Teal

              3,77411339




              3,77411339








              • 2





                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 3 '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 3 '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 3 '15 at 0:21











              • @cxrodgers then just lib, I assumed you'd have a 64bit system

                – Alec Teal
                Jan 3 '15 at 1:27






              • 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 xahlee.info/UnixResource_dir/_/ldpath.html

                – Britton Kerin
                Aug 26 '17 at 13:19














              • 2





                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 3 '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 3 '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 3 '15 at 0:21











              • @cxrodgers then just lib, I assumed you'd have a 64bit system

                – Alec Teal
                Jan 3 '15 at 1:27






              • 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 xahlee.info/UnixResource_dir/_/ldpath.html

                – Britton Kerin
                Aug 26 '17 at 13:19








              2




              2





              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 3 '13 at 17:00





              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 3 '13 at 17:00




              1




              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 3 '13 at 17:10





              @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 3 '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 3 '15 at 0:21





              What if the directory /usr/local/lib64 does not exist? I do have libstdc++6 and gcc 4.8 installed.

              – cxrodgers
              Jan 3 '15 at 0:21













              @cxrodgers then just lib, I assumed you'd have a 64bit system

              – Alec Teal
              Jan 3 '15 at 1:27





              @cxrodgers then just lib, I assumed you'd have a 64bit system

              – Alec Teal
              Jan 3 '15 at 1:27




              2




              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 xahlee.info/UnixResource_dir/_/ldpath.html

              – Britton Kerin
              Aug 26 '17 at 13:19





              @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 xahlee.info/UnixResource_dir/_/ldpath.html

              – Britton Kerin
              Aug 26 '17 at 13:19













              18














              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





              share|improve this answer




























                18














                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





                share|improve this answer


























                  18












                  18








                  18







                  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





                  share|improve this answer













                  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






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Jun 4 '16 at 9:18









                  FootnikoFootniko

                  1,24911827




                  1,24911827























                      6














                      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.






                      share|improve this answer





















                      • 2





                        Doesn't work. Still gives the same error.

                        – Akshay Hazari
                        Jul 31 '17 at 8:51











                      • what if I don't have sudo access? then how can implement your approach?

                        – Rishabh Agrahari
                        Dec 10 '18 at 20:08
















                      6














                      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.






                      share|improve this answer





















                      • 2





                        Doesn't work. Still gives the same error.

                        – Akshay Hazari
                        Jul 31 '17 at 8:51











                      • what if I don't have sudo access? then how can implement your approach?

                        – Rishabh Agrahari
                        Dec 10 '18 at 20:08














                      6












                      6








                      6







                      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.






                      share|improve this answer















                      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.







                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Apr 13 '17 at 12:22









                      Community

                      11




                      11










                      answered Jun 17 '16 at 6:12









                      Yuliia AshomokYuliia Ashomok

                      4,03413748




                      4,03413748








                      • 2





                        Doesn't work. Still gives the same error.

                        – Akshay Hazari
                        Jul 31 '17 at 8:51











                      • what if I don't have sudo access? then how can implement your approach?

                        – Rishabh Agrahari
                        Dec 10 '18 at 20:08














                      • 2





                        Doesn't work. Still gives the same error.

                        – Akshay Hazari
                        Jul 31 '17 at 8:51











                      • what if I don't have sudo access? then how can implement your approach?

                        – Rishabh Agrahari
                        Dec 10 '18 at 20:08








                      2




                      2





                      Doesn't work. Still gives the same error.

                      – Akshay Hazari
                      Jul 31 '17 at 8:51





                      Doesn't work. Still gives the same error.

                      – Akshay Hazari
                      Jul 31 '17 at 8:51













                      what if I don't have sudo access? then how can implement your approach?

                      – Rishabh Agrahari
                      Dec 10 '18 at 20:08





                      what if I don't have sudo access? then how can implement your approach?

                      – Rishabh Agrahari
                      Dec 10 '18 at 20:08











                      2














                      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






                      share|improve this answer




























                        2














                        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






                        share|improve this answer


























                          2












                          2








                          2







                          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






                          share|improve this answer













                          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







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Jun 16 '16 at 9:41









                          Vipin JainVipin Jain

                          3,8801435




                          3,8801435























                              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






                              share|improve this answer






























                                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






                                share|improve this answer




























                                  1












                                  1








                                  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






                                  share|improve this answer















                                  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







                                  share|improve this answer














                                  share|improve this answer



                                  share|improve this answer








                                  edited Apr 13 '17 at 12:22









                                  Community

                                  11




                                  11










                                  answered Nov 27 '15 at 8:39









                                  Marek TichyMarek Tichy

                                  192




                                  192























                                      0














                                      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()





                                      share|improve this answer




























                                        0














                                        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()





                                        share|improve this answer


























                                          0












                                          0








                                          0







                                          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()





                                          share|improve this answer













                                          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()






                                          share|improve this answer












                                          share|improve this answer



                                          share|improve this answer










                                          answered Oct 9 '15 at 15:58









                                          Ogi MooreOgi Moore

                                          566




                                          566























                                              0














                                              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 :).






                                              share|improve this answer




























                                                0














                                                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 :).






                                                share|improve this answer


























                                                  0












                                                  0








                                                  0







                                                  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 :).






                                                  share|improve this answer













                                                  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 :).







                                                  share|improve this answer












                                                  share|improve this answer



                                                  share|improve this answer










                                                  answered Aug 26 '17 at 13:54









                                                  Britton KerinBritton Kerin

                                                  816




                                                  816























                                                      0














                                                      In my case it was gcc 6 the one missing




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






                                                      share|improve this answer






























                                                        0














                                                        In my case it was gcc 6 the one missing




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






                                                        share|improve this answer




























                                                          0












                                                          0








                                                          0







                                                          In my case it was gcc 6 the one missing




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






                                                          share|improve this answer















                                                          In my case it was gcc 6 the one missing




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







                                                          share|improve this answer














                                                          share|improve this answer



                                                          share|improve this answer








                                                          edited Dec 4 '18 at 14:09

























                                                          answered Nov 22 '18 at 10:31









                                                          Jose OspinaJose Ospina

                                                          9411430




                                                          9411430















                                                              Popular posts from this blog

                                                              If I really need a card on my start hand, how many mulligans make sense? [duplicate]

                                                              Alcedinidae

                                                              Can an atomic nucleus contain both particles and antiparticles? [duplicate]