Installing missing symbol file libstdc++-libc6.1-1.so.2 on Linux Mint 17
I am trying to execute a cellular automata program on Linux Mint 17, and I get the following error:
./simu: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory
I have libstdc++ installed, and there is no file in there containing the name libstdc++-libc.
I have checked many other solutions, but nothing seems to work. I am therefore wondering what I should do to find and install the missing file. This is for a school project, so any help would be greatly appreciated.
symbols libc libstdc++
add a comment |
I am trying to execute a cellular automata program on Linux Mint 17, and I get the following error:
./simu: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory
I have libstdc++ installed, and there is no file in there containing the name libstdc++-libc.
I have checked many other solutions, but nothing seems to work. I am therefore wondering what I should do to find and install the missing file. This is for a school project, so any help would be greatly appreciated.
symbols libc libstdc++
It is useful to give a brief description of already tried solutions, this is useful in order to track the real problem
– Fabiano Tarlao
Nov 21 '18 at 18:32
add a comment |
I am trying to execute a cellular automata program on Linux Mint 17, and I get the following error:
./simu: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory
I have libstdc++ installed, and there is no file in there containing the name libstdc++-libc.
I have checked many other solutions, but nothing seems to work. I am therefore wondering what I should do to find and install the missing file. This is for a school project, so any help would be greatly appreciated.
symbols libc libstdc++
I am trying to execute a cellular automata program on Linux Mint 17, and I get the following error:
./simu: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory
I have libstdc++ installed, and there is no file in there containing the name libstdc++-libc.
I have checked many other solutions, but nothing seems to work. I am therefore wondering what I should do to find and install the missing file. This is for a school project, so any help would be greatly appreciated.
symbols libc libstdc++
symbols libc libstdc++
asked Nov 21 '18 at 18:01
DarthMallocDarthMalloc
246
246
It is useful to give a brief description of already tried solutions, this is useful in order to track the real problem
– Fabiano Tarlao
Nov 21 '18 at 18:32
add a comment |
It is useful to give a brief description of already tried solutions, this is useful in order to track the real problem
– Fabiano Tarlao
Nov 21 '18 at 18:32
It is useful to give a brief description of already tried solutions, this is useful in order to track the real problem
– Fabiano Tarlao
Nov 21 '18 at 18:32
It is useful to give a brief description of already tried solutions, this is useful in order to track the real problem
– Fabiano Tarlao
Nov 21 '18 at 18:32
add a comment |
1 Answer
1
active
oldest
votes
Please provide more details
You can obtain useful proofs about your binary (simu) with the file
command:
file path/to/the/simu
You can also double check with ldd
the exact name of the libraries the binary is looking for:
ldd path/to/the/simu
Please provide the output of the previous commands in order to help answering your question.
Meanwhile, one possible answer could be..
I suppose the binary has been compiled on a RedHat/Fedora/Centos by using their compat-lib* package (that provides the libstdc++-libc
lib).
I think/suppose there is not the same compat-*
package and library in Mint/Ubuntu, but being compiled with such a library, perhaps, it should work by creating a proper symbolic link, by hand, in library path. The symbolic link should point to one of the installed libstdc++
dynamic libraries in your system)
e.g., you can create a link from /usr/lib/x86_64-linux-gnu/libstdc++-libc6.1-1.so.2
to /usr/lib/x86_64-linux-gnu/libstdc++.so.?
where ? is the smaller version number that you find in your system.
Command example (you have to adapt it for sure):
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/lib/x86_64-linux-gnu/libstdc++-libc6.1-1.so.2
There are also cases (depending the binary is compiled on 32 or 64 bits) where you need to change the path x86_64-linux-gnu
into i386-linux-gnu
. You have to try and adapt to your case.
This is an hypothetical rough hack, no guarantees :-) in fact I'm just curious.
Cleaner way
In order to not pollute your OS/system with links, you can create a new folder, name it "customlibs", in the same place you have the program/binary.
You can create the links for each not-matching library filenames, inside that folder, e.g.:
ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ./customlibs/libstdc++-libc6.1-1.so.2
Then, in order to execute the program, open a terminal and from cli change the LD_LIBRARY
enviroment variable with this command:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/absolute/path/to/customlibs
in this way, the system looks in customlibs
too for libs.
In the same terminal, execute the program:
./simu
In this way you don't mess with the system.
You need to be very lucky
It is quite simpler to perform the job in "Cleaner way" when copying the required libraries from the system the binary has been compiled in.
It is also a more reliable way, I have performed this few times.
The hack we are performing now, linking with the current system libs, is a bit "harder". Good luck.
Thank you very much for getting back to me. From the first command I got
– DarthMalloc
Nov 22 '18 at 19:35
simu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped and for the second I got linux-gate.so.1 => (0xf77a7000) libstdc++-libc6.1-1.so.2 => not found libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7717000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7566000) /lib/ld-linux.so.2 (0xf77a8000) I will try the linking command next. Can the linking command cause any problems for the rest of the system.
– DarthMalloc
Nov 22 '18 at 19:50
First, you can note that you have a 32 (386) bit binary, so you need to link the /lib/i386-linux-gnu libs and not the x64 ones. Also note that you lack both libstdc++-libc6.1-1.so.2 and libm.so.6.so, the second is quite strange, please check if you have this library installed. Usually when you do not overwrite files that are already there, you break nothing but it's a bit messy. I'll add a suggestion to my answer about a cleaner way to create the link. Please consider that these are hacks that work better when you copy in a folder/use the libraries from the old OS where the binary come from
– Fabiano Tarlao
Nov 22 '18 at 21:39
added a "cleaner way" section, let's try.. but you have to be very lucky. It could be very useful to know the distro name this binary comes from, or, in the case you have access to that system, if you can copy files from that system. Regads
– Fabiano Tarlao
Nov 22 '18 at 22:05
Please update the thread with the final outcome (success/failure), it is the most important contribution ;-)
– Fabiano Tarlao
Nov 23 '18 at 8:13
|
show 3 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53418057%2finstalling-missing-symbol-file-libstdc-libc6-1-1-so-2-on-linux-mint-17%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Please provide more details
You can obtain useful proofs about your binary (simu) with the file
command:
file path/to/the/simu
You can also double check with ldd
the exact name of the libraries the binary is looking for:
ldd path/to/the/simu
Please provide the output of the previous commands in order to help answering your question.
Meanwhile, one possible answer could be..
I suppose the binary has been compiled on a RedHat/Fedora/Centos by using their compat-lib* package (that provides the libstdc++-libc
lib).
I think/suppose there is not the same compat-*
package and library in Mint/Ubuntu, but being compiled with such a library, perhaps, it should work by creating a proper symbolic link, by hand, in library path. The symbolic link should point to one of the installed libstdc++
dynamic libraries in your system)
e.g., you can create a link from /usr/lib/x86_64-linux-gnu/libstdc++-libc6.1-1.so.2
to /usr/lib/x86_64-linux-gnu/libstdc++.so.?
where ? is the smaller version number that you find in your system.
Command example (you have to adapt it for sure):
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/lib/x86_64-linux-gnu/libstdc++-libc6.1-1.so.2
There are also cases (depending the binary is compiled on 32 or 64 bits) where you need to change the path x86_64-linux-gnu
into i386-linux-gnu
. You have to try and adapt to your case.
This is an hypothetical rough hack, no guarantees :-) in fact I'm just curious.
Cleaner way
In order to not pollute your OS/system with links, you can create a new folder, name it "customlibs", in the same place you have the program/binary.
You can create the links for each not-matching library filenames, inside that folder, e.g.:
ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ./customlibs/libstdc++-libc6.1-1.so.2
Then, in order to execute the program, open a terminal and from cli change the LD_LIBRARY
enviroment variable with this command:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/absolute/path/to/customlibs
in this way, the system looks in customlibs
too for libs.
In the same terminal, execute the program:
./simu
In this way you don't mess with the system.
You need to be very lucky
It is quite simpler to perform the job in "Cleaner way" when copying the required libraries from the system the binary has been compiled in.
It is also a more reliable way, I have performed this few times.
The hack we are performing now, linking with the current system libs, is a bit "harder". Good luck.
Thank you very much for getting back to me. From the first command I got
– DarthMalloc
Nov 22 '18 at 19:35
simu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped and for the second I got linux-gate.so.1 => (0xf77a7000) libstdc++-libc6.1-1.so.2 => not found libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7717000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7566000) /lib/ld-linux.so.2 (0xf77a8000) I will try the linking command next. Can the linking command cause any problems for the rest of the system.
– DarthMalloc
Nov 22 '18 at 19:50
First, you can note that you have a 32 (386) bit binary, so you need to link the /lib/i386-linux-gnu libs and not the x64 ones. Also note that you lack both libstdc++-libc6.1-1.so.2 and libm.so.6.so, the second is quite strange, please check if you have this library installed. Usually when you do not overwrite files that are already there, you break nothing but it's a bit messy. I'll add a suggestion to my answer about a cleaner way to create the link. Please consider that these are hacks that work better when you copy in a folder/use the libraries from the old OS where the binary come from
– Fabiano Tarlao
Nov 22 '18 at 21:39
added a "cleaner way" section, let's try.. but you have to be very lucky. It could be very useful to know the distro name this binary comes from, or, in the case you have access to that system, if you can copy files from that system. Regads
– Fabiano Tarlao
Nov 22 '18 at 22:05
Please update the thread with the final outcome (success/failure), it is the most important contribution ;-)
– Fabiano Tarlao
Nov 23 '18 at 8:13
|
show 3 more comments
Please provide more details
You can obtain useful proofs about your binary (simu) with the file
command:
file path/to/the/simu
You can also double check with ldd
the exact name of the libraries the binary is looking for:
ldd path/to/the/simu
Please provide the output of the previous commands in order to help answering your question.
Meanwhile, one possible answer could be..
I suppose the binary has been compiled on a RedHat/Fedora/Centos by using their compat-lib* package (that provides the libstdc++-libc
lib).
I think/suppose there is not the same compat-*
package and library in Mint/Ubuntu, but being compiled with such a library, perhaps, it should work by creating a proper symbolic link, by hand, in library path. The symbolic link should point to one of the installed libstdc++
dynamic libraries in your system)
e.g., you can create a link from /usr/lib/x86_64-linux-gnu/libstdc++-libc6.1-1.so.2
to /usr/lib/x86_64-linux-gnu/libstdc++.so.?
where ? is the smaller version number that you find in your system.
Command example (you have to adapt it for sure):
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/lib/x86_64-linux-gnu/libstdc++-libc6.1-1.so.2
There are also cases (depending the binary is compiled on 32 or 64 bits) where you need to change the path x86_64-linux-gnu
into i386-linux-gnu
. You have to try and adapt to your case.
This is an hypothetical rough hack, no guarantees :-) in fact I'm just curious.
Cleaner way
In order to not pollute your OS/system with links, you can create a new folder, name it "customlibs", in the same place you have the program/binary.
You can create the links for each not-matching library filenames, inside that folder, e.g.:
ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ./customlibs/libstdc++-libc6.1-1.so.2
Then, in order to execute the program, open a terminal and from cli change the LD_LIBRARY
enviroment variable with this command:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/absolute/path/to/customlibs
in this way, the system looks in customlibs
too for libs.
In the same terminal, execute the program:
./simu
In this way you don't mess with the system.
You need to be very lucky
It is quite simpler to perform the job in "Cleaner way" when copying the required libraries from the system the binary has been compiled in.
It is also a more reliable way, I have performed this few times.
The hack we are performing now, linking with the current system libs, is a bit "harder". Good luck.
Thank you very much for getting back to me. From the first command I got
– DarthMalloc
Nov 22 '18 at 19:35
simu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped and for the second I got linux-gate.so.1 => (0xf77a7000) libstdc++-libc6.1-1.so.2 => not found libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7717000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7566000) /lib/ld-linux.so.2 (0xf77a8000) I will try the linking command next. Can the linking command cause any problems for the rest of the system.
– DarthMalloc
Nov 22 '18 at 19:50
First, you can note that you have a 32 (386) bit binary, so you need to link the /lib/i386-linux-gnu libs and not the x64 ones. Also note that you lack both libstdc++-libc6.1-1.so.2 and libm.so.6.so, the second is quite strange, please check if you have this library installed. Usually when you do not overwrite files that are already there, you break nothing but it's a bit messy. I'll add a suggestion to my answer about a cleaner way to create the link. Please consider that these are hacks that work better when you copy in a folder/use the libraries from the old OS where the binary come from
– Fabiano Tarlao
Nov 22 '18 at 21:39
added a "cleaner way" section, let's try.. but you have to be very lucky. It could be very useful to know the distro name this binary comes from, or, in the case you have access to that system, if you can copy files from that system. Regads
– Fabiano Tarlao
Nov 22 '18 at 22:05
Please update the thread with the final outcome (success/failure), it is the most important contribution ;-)
– Fabiano Tarlao
Nov 23 '18 at 8:13
|
show 3 more comments
Please provide more details
You can obtain useful proofs about your binary (simu) with the file
command:
file path/to/the/simu
You can also double check with ldd
the exact name of the libraries the binary is looking for:
ldd path/to/the/simu
Please provide the output of the previous commands in order to help answering your question.
Meanwhile, one possible answer could be..
I suppose the binary has been compiled on a RedHat/Fedora/Centos by using their compat-lib* package (that provides the libstdc++-libc
lib).
I think/suppose there is not the same compat-*
package and library in Mint/Ubuntu, but being compiled with such a library, perhaps, it should work by creating a proper symbolic link, by hand, in library path. The symbolic link should point to one of the installed libstdc++
dynamic libraries in your system)
e.g., you can create a link from /usr/lib/x86_64-linux-gnu/libstdc++-libc6.1-1.so.2
to /usr/lib/x86_64-linux-gnu/libstdc++.so.?
where ? is the smaller version number that you find in your system.
Command example (you have to adapt it for sure):
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/lib/x86_64-linux-gnu/libstdc++-libc6.1-1.so.2
There are also cases (depending the binary is compiled on 32 or 64 bits) where you need to change the path x86_64-linux-gnu
into i386-linux-gnu
. You have to try and adapt to your case.
This is an hypothetical rough hack, no guarantees :-) in fact I'm just curious.
Cleaner way
In order to not pollute your OS/system with links, you can create a new folder, name it "customlibs", in the same place you have the program/binary.
You can create the links for each not-matching library filenames, inside that folder, e.g.:
ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ./customlibs/libstdc++-libc6.1-1.so.2
Then, in order to execute the program, open a terminal and from cli change the LD_LIBRARY
enviroment variable with this command:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/absolute/path/to/customlibs
in this way, the system looks in customlibs
too for libs.
In the same terminal, execute the program:
./simu
In this way you don't mess with the system.
You need to be very lucky
It is quite simpler to perform the job in "Cleaner way" when copying the required libraries from the system the binary has been compiled in.
It is also a more reliable way, I have performed this few times.
The hack we are performing now, linking with the current system libs, is a bit "harder". Good luck.
Please provide more details
You can obtain useful proofs about your binary (simu) with the file
command:
file path/to/the/simu
You can also double check with ldd
the exact name of the libraries the binary is looking for:
ldd path/to/the/simu
Please provide the output of the previous commands in order to help answering your question.
Meanwhile, one possible answer could be..
I suppose the binary has been compiled on a RedHat/Fedora/Centos by using their compat-lib* package (that provides the libstdc++-libc
lib).
I think/suppose there is not the same compat-*
package and library in Mint/Ubuntu, but being compiled with such a library, perhaps, it should work by creating a proper symbolic link, by hand, in library path. The symbolic link should point to one of the installed libstdc++
dynamic libraries in your system)
e.g., you can create a link from /usr/lib/x86_64-linux-gnu/libstdc++-libc6.1-1.so.2
to /usr/lib/x86_64-linux-gnu/libstdc++.so.?
where ? is the smaller version number that you find in your system.
Command example (you have to adapt it for sure):
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/lib/x86_64-linux-gnu/libstdc++-libc6.1-1.so.2
There are also cases (depending the binary is compiled on 32 or 64 bits) where you need to change the path x86_64-linux-gnu
into i386-linux-gnu
. You have to try and adapt to your case.
This is an hypothetical rough hack, no guarantees :-) in fact I'm just curious.
Cleaner way
In order to not pollute your OS/system with links, you can create a new folder, name it "customlibs", in the same place you have the program/binary.
You can create the links for each not-matching library filenames, inside that folder, e.g.:
ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ./customlibs/libstdc++-libc6.1-1.so.2
Then, in order to execute the program, open a terminal and from cli change the LD_LIBRARY
enviroment variable with this command:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/absolute/path/to/customlibs
in this way, the system looks in customlibs
too for libs.
In the same terminal, execute the program:
./simu
In this way you don't mess with the system.
You need to be very lucky
It is quite simpler to perform the job in "Cleaner way" when copying the required libraries from the system the binary has been compiled in.
It is also a more reliable way, I have performed this few times.
The hack we are performing now, linking with the current system libs, is a bit "harder". Good luck.
edited Nov 23 '18 at 8:27
answered Nov 21 '18 at 19:17
Fabiano TarlaoFabiano Tarlao
1,3091723
1,3091723
Thank you very much for getting back to me. From the first command I got
– DarthMalloc
Nov 22 '18 at 19:35
simu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped and for the second I got linux-gate.so.1 => (0xf77a7000) libstdc++-libc6.1-1.so.2 => not found libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7717000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7566000) /lib/ld-linux.so.2 (0xf77a8000) I will try the linking command next. Can the linking command cause any problems for the rest of the system.
– DarthMalloc
Nov 22 '18 at 19:50
First, you can note that you have a 32 (386) bit binary, so you need to link the /lib/i386-linux-gnu libs and not the x64 ones. Also note that you lack both libstdc++-libc6.1-1.so.2 and libm.so.6.so, the second is quite strange, please check if you have this library installed. Usually when you do not overwrite files that are already there, you break nothing but it's a bit messy. I'll add a suggestion to my answer about a cleaner way to create the link. Please consider that these are hacks that work better when you copy in a folder/use the libraries from the old OS where the binary come from
– Fabiano Tarlao
Nov 22 '18 at 21:39
added a "cleaner way" section, let's try.. but you have to be very lucky. It could be very useful to know the distro name this binary comes from, or, in the case you have access to that system, if you can copy files from that system. Regads
– Fabiano Tarlao
Nov 22 '18 at 22:05
Please update the thread with the final outcome (success/failure), it is the most important contribution ;-)
– Fabiano Tarlao
Nov 23 '18 at 8:13
|
show 3 more comments
Thank you very much for getting back to me. From the first command I got
– DarthMalloc
Nov 22 '18 at 19:35
simu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped and for the second I got linux-gate.so.1 => (0xf77a7000) libstdc++-libc6.1-1.so.2 => not found libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7717000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7566000) /lib/ld-linux.so.2 (0xf77a8000) I will try the linking command next. Can the linking command cause any problems for the rest of the system.
– DarthMalloc
Nov 22 '18 at 19:50
First, you can note that you have a 32 (386) bit binary, so you need to link the /lib/i386-linux-gnu libs and not the x64 ones. Also note that you lack both libstdc++-libc6.1-1.so.2 and libm.so.6.so, the second is quite strange, please check if you have this library installed. Usually when you do not overwrite files that are already there, you break nothing but it's a bit messy. I'll add a suggestion to my answer about a cleaner way to create the link. Please consider that these are hacks that work better when you copy in a folder/use the libraries from the old OS where the binary come from
– Fabiano Tarlao
Nov 22 '18 at 21:39
added a "cleaner way" section, let's try.. but you have to be very lucky. It could be very useful to know the distro name this binary comes from, or, in the case you have access to that system, if you can copy files from that system. Regads
– Fabiano Tarlao
Nov 22 '18 at 22:05
Please update the thread with the final outcome (success/failure), it is the most important contribution ;-)
– Fabiano Tarlao
Nov 23 '18 at 8:13
Thank you very much for getting back to me. From the first command I got
– DarthMalloc
Nov 22 '18 at 19:35
Thank you very much for getting back to me. From the first command I got
– DarthMalloc
Nov 22 '18 at 19:35
simu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped and for the second I got linux-gate.so.1 => (0xf77a7000) libstdc++-libc6.1-1.so.2 => not found libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7717000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7566000) /lib/ld-linux.so.2 (0xf77a8000) I will try the linking command next. Can the linking command cause any problems for the rest of the system.
– DarthMalloc
Nov 22 '18 at 19:50
simu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped and for the second I got linux-gate.so.1 => (0xf77a7000) libstdc++-libc6.1-1.so.2 => not found libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7717000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7566000) /lib/ld-linux.so.2 (0xf77a8000) I will try the linking command next. Can the linking command cause any problems for the rest of the system.
– DarthMalloc
Nov 22 '18 at 19:50
First, you can note that you have a 32 (386) bit binary, so you need to link the /lib/i386-linux-gnu libs and not the x64 ones. Also note that you lack both libstdc++-libc6.1-1.so.2 and libm.so.6.so, the second is quite strange, please check if you have this library installed. Usually when you do not overwrite files that are already there, you break nothing but it's a bit messy. I'll add a suggestion to my answer about a cleaner way to create the link. Please consider that these are hacks that work better when you copy in a folder/use the libraries from the old OS where the binary come from
– Fabiano Tarlao
Nov 22 '18 at 21:39
First, you can note that you have a 32 (386) bit binary, so you need to link the /lib/i386-linux-gnu libs and not the x64 ones. Also note that you lack both libstdc++-libc6.1-1.so.2 and libm.so.6.so, the second is quite strange, please check if you have this library installed. Usually when you do not overwrite files that are already there, you break nothing but it's a bit messy. I'll add a suggestion to my answer about a cleaner way to create the link. Please consider that these are hacks that work better when you copy in a folder/use the libraries from the old OS where the binary come from
– Fabiano Tarlao
Nov 22 '18 at 21:39
added a "cleaner way" section, let's try.. but you have to be very lucky. It could be very useful to know the distro name this binary comes from, or, in the case you have access to that system, if you can copy files from that system. Regads
– Fabiano Tarlao
Nov 22 '18 at 22:05
added a "cleaner way" section, let's try.. but you have to be very lucky. It could be very useful to know the distro name this binary comes from, or, in the case you have access to that system, if you can copy files from that system. Regads
– Fabiano Tarlao
Nov 22 '18 at 22:05
Please update the thread with the final outcome (success/failure), it is the most important contribution ;-)
– Fabiano Tarlao
Nov 23 '18 at 8:13
Please update the thread with the final outcome (success/failure), it is the most important contribution ;-)
– Fabiano Tarlao
Nov 23 '18 at 8:13
|
show 3 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53418057%2finstalling-missing-symbol-file-libstdc-libc6-1-1-so-2-on-linux-mint-17%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It is useful to give a brief description of already tried solutions, this is useful in order to track the real problem
– Fabiano Tarlao
Nov 21 '18 at 18:32