Rob
26-10-2005, 04:38 AM
Just trying to find this file from somewhere. Any links?
Thanks.
Thanks.
|
View Full Version : where can I get libm.so.1? Rob 26-10-2005, 04:38 AM Just trying to find this file from somewhere. Any links? Thanks. Moe Trin 27-10-2005, 01:20 PM In the Usenet newsgroup comp.os.linux.embedded, in article <1130254711.645238.229100@g49g2000cwa.googlegroups. com>, Rob wrote: >Just trying to find this file from somewhere. Any links? Might be nice to have some perspective. "libm" is the math library of the normal GNU libraries - but the file name you list is rather unusual. "libm.so.4" was the old a.out version from the early 1990s. 'libm.so.5' is the libc5 version from the mid 1990s, and libm.so.6 is from Glibc2 - the "current" libraries used by most Linux distributions. Old guy Rob 27-10-2005, 09:28 PM Here's some more information. I am complete novice at using Linux, so please bear with me if I seem a bit clueless. I have been given some code (source code, Makefile, Configure file, compiled and linked code ) that I need to get working on a redhat box. The executable code seems to have been made on a SuSe box. Running the application I received the following message "error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory" I managed to locate this file using google and placed it into /usr/lib. This seemed to solve that problem. However, the application now reports. "error while loading shared libraries: libm.so.1: cannot open shared object file: No such file or directory" Hence my search for libm.so.1 This all seems a bit weird to me coming from a windows environment. I have an extreme dislike of VisualBasic and its need to have lots of precompiled libraries installed before any executable code will run. It looks like Linux applications use the same methodology as VB for distributing applications. Is there a way of including all code in the executable when doing a Make,thus ending up with more portable executable code? Thanks for any responses Captain Dondo 28-10-2005, 03:05 AM On Thu, 27 Oct 2005 01:28:09 -0700, Rob wrote: > Here's some more information. > > I am complete novice at using Linux, so please bear with me if I seem a > bit clueless. > > I have been given some code (source code, Makefile, Configure file, > compiled and linked code ) that I need to get working on a redhat box. > The executable code seems to have been made on a SuSe box. Which RedHat? (How old is it?) > > Running the application I received the following message > > "error while loading shared libraries: libstdc++.so.5: cannot open > shared object file: No such file or directory" > > I managed to locate this file using google and placed it into /usr/lib. > > This seemed to solve that problem. However, the application now > reports. > > "error while loading shared libraries: libm.so.1: cannot open shared > object file: No such file or directory" > > Hence my search for libm.so.1 OK, it sounds like you may have an old binary.... If you have the sourcecode, the easiest thing may be to just recompile it for your system. > > This all seems a bit weird to me coming from a windows environment. I > have an extreme dislike of VisualBasic and its need to have lots of > precompiled libraries installed before any executable code will run. > > It looks like Linux applications use the same methodology as VB for > distributing applications. Is there a way of including all code in the > executable when doing a Make,thus ending up with more portable > executable code? You are talking about static linking. Yes, it can be done. The advantage of dynamic linking is that you get smaller binaries, at the expense of runtime dependencies. What you really ought to do is learn about rpm to manage files. Rather than randomly going out and sticking libs in places, use rpmfind or similar to find the proper rpm for your version of linux. Then use yum or whatever to get it along with all of the dependencies. http://www.rpmfind.net/linux/rpm2html/search.php?query=libstdc%2B%2B.so.5&submit=Search+... Moe Trin 28-10-2005, 01:27 PM In the Usenet newsgroup comp.os.linux.embedded, in article <1130401689.337850.277530@g43g2000cwa.googlegroups. com>, Rob wrote: >I have been given some code (source code, Makefile, Configure file, >compiled and linked code ) that I need to get working on a redhat box. >The executable code seems to have been made on a SuSe box. OK - over you go to 'alt.os.linux.suse' if that's on your server, but note that some people killfile all posts from google.com. Ask what package that library might be in. While Linux is the kernel, and the distributions tend to follow the "Linux System Base" (http://www.linuxbase.org/spec/), distributions are not identical. >"error while loading shared libraries: libstdc++.so.5: cannot open >shared object file: No such file or directory" > >I managed to locate this file using google and placed it into /usr/lib. You should ask the author what _version_ he wants - this information might be in the documentation that comes with the code. >"error while loading shared libraries: libm.so.1: cannot open shared >object file: No such file or directory" > >Hence my search for libm.so.1 This _might be_ solvable by creating that link and pointing it to whichever libm your have - and then again, it may not. >This all seems a bit weird to me coming from a windows environment. I >have an extreme dislike of VisualBasic and its need to have lots of >precompiled libraries installed before any executable code will run. Sorry - where do you think microsoft got that concept? This has been the case for decades. [compton ~]$ zgrep lib rpms.fc4.gz | grep -vc devel 157 [compton ~]$ 157 libraries in Fedora Core 4. >It looks like Linux applications use the same methodology as VB for >distributing applications. Other way around ;-) Microsoft hasn't invented anything, ever. >Is there a way of including all code in the executable when doing a >Make,thus ending up with more portable executable code? The keyword is 'static' - the problem with it is that the executable is substantially larger. Under _normal_ conditions, everything gets compiled against a standard set of libraries, and the resulting binary is pretty small. The runtime libraries are large, but these are shared by all binaries that need them. Old guy |