Online Loans - Loans - Loan - Free Online Greeting Cards : Meme4u - Buy PSP
where can I get libm.so.1? [Archive] - DunLUG - Dunedin Linux Users Group

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