Installing missing symbol file libstdc++-libc6.1-1.so.2 on Linux Mint 17












0















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.










share|improve this question























  • 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
















0















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.










share|improve this question























  • 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














0












0








0








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.










share|improve this question














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++






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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



















  • 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












1 Answer
1






active

oldest

votes


















0














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.






share|improve this answer


























  • 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











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
});


}
});














draft saved

draft discarded


















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









0














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.






share|improve this answer


























  • 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
















0














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.






share|improve this answer


























  • 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














0












0








0







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








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



















  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Costa Masnaga

Fotorealismo

Sidney Franklin