/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.8' not found [closed]
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
closed as off-topic by E_net4 is kind and welcoming, Toby Speight, jww, Makyen, Pearly Spencer Nov 24 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 is kind and welcoming, Toby Speight, Pearly Spencer
If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
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
closed as off-topic by E_net4 is kind and welcoming, Toby Speight, jww, Makyen, Pearly Spencer Nov 24 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 is kind and welcoming, 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 at 7:53
add a comment |
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
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
c++ linux unix
edited Nov 23 at 17:35
jww
52.6k39221482
52.6k39221482
asked Dec 3 '13 at 16:52
Alec Teal
3,73711239
3,73711239
closed as off-topic by E_net4 is kind and welcoming, Toby Speight, jww, Makyen, Pearly Spencer Nov 24 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 is kind and welcoming, 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 is kind and welcoming, Toby Speight, jww, Makyen, Pearly Spencer Nov 24 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 is kind and welcoming, 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 at 7:53
add a comment |
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 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 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 at 7:53
add a comment |
8 Answers
8
active
oldest
votes
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?
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
|
show 6 more comments
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
add a comment |
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.
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 at 20:08
add a comment |
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
add a comment |
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
add a comment |
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()
add a comment |
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 :).
add a comment |
In my case it was gcc 6 the one missing
sudo apt-get install gcc-6 g++-6 -y
add a comment |
8 Answers
8
active
oldest
votes
8 Answers
8
active
oldest
votes
active
oldest
votes
active
oldest
votes
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?
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
|
show 6 more comments
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?
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
|
show 6 more comments
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?
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?
answered Dec 3 '13 at 16:52
Alec Teal
3,73711239
3,73711239
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
|
show 6 more comments
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
|
show 6 more comments
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
add a comment |
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
add a comment |
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
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
answered Jun 4 '16 at 9:18
Footniko
1,17911627
1,17911627
add a comment |
add a comment |
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.
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 at 20:08
add a comment |
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.
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 at 20:08
add a comment |
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.
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.
edited Apr 13 '17 at 12:22
Community♦
11
11
answered Jun 17 '16 at 6:12
Yuliia Ashomok
3,85113748
3,85113748
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 at 20:08
add a comment |
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 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 at 20:08
what if I don't have sudo access? then how can implement your approach?
– Rishabh Agrahari
Dec 10 at 20:08
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Jun 16 '16 at 9:41
Vipin Jain
3,8001435
3,8001435
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
edited Apr 13 '17 at 12:22
Community♦
11
11
answered Nov 27 '15 at 8:39
Marek Tichy
192
192
add a comment |
add a comment |
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()
add a comment |
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()
add a comment |
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()
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()
answered Oct 9 '15 at 15:58
Ogi Moore
566
566
add a comment |
add a comment |
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 :).
add a comment |
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 :).
add a comment |
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 :).
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 :).
answered Aug 26 '17 at 13:54
Britton Kerin
816
816
add a comment |
add a comment |
In my case it was gcc 6 the one missing
sudo apt-get install gcc-6 g++-6 -y
add a comment |
In my case it was gcc 6 the one missing
sudo apt-get install gcc-6 g++-6 -y
add a comment |
In my case it was gcc 6 the one missing
sudo apt-get install gcc-6 g++-6 -y
In my case it was gcc 6 the one missing
sudo apt-get install gcc-6 g++-6 -y
edited Dec 4 at 14:09
answered Nov 22 at 10:31
Jose Ospina
9061430
9061430
add a comment |
add a comment |
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 at 7:53