Re: How do I install this missing library?

From: Rick Moen (rick_at_linuxmafia.com)
Date: 09/20/05 

Date: Tue, 20 Sep 2005 01:24:00 -0400

Random Penguin <nonexistent2032@yahoo.co.uk> wrote:
> Hi guys...
>
> work@home:~/lstc/lsopt_2.2/Executables/LSOPT_EXE> ldd lsopt
> linux-gate.so.1 => (0xffffe000)
> libg2c.so.0 => not found
> libm.so.6 => /lib/tls/libm.so.6 (0x4002a000)
> libc.so.6 => /lib/tls/libc.so.6 (0x4004d000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> Yes, I tried Googling for it. The suggested command:
> ./configure --enable-languages=c,c++,f77
>
> doesn't work. I get:
> work@home:~/lstc/lsopt_2.2/Executables/LSOPT_EXE> ./configure
> -bash: ./configure: No such file or directory

Greetings again. Elsewhere in this thread, you'll notice I warned you
that computer geeks have a ghastly tendency to answer questions exactly
as posed -- even if they're quietly thinking to themselves "But _why_
would the user want to do that?"

In this case, you inadvertantly framed the question as "Why am I getting
"No such file or directory" when I type "./configure"?

But, reading your post carefully, that is _not_ the problem you really
wanted to solve. You have some sort of (locally installed, I guess)
binary called "lsopt" that is trying to dereference (locate and load)
library "libg2c.so.0" and failing -- on a SUSE Linux 9.2. system.

Impliedly, your big-picture question is: "How can I run lsopt?"

Maybe, you grabbed a binary copy of Livermore Software Technology Corp's
LS-OPT, the optimization and probabilistic analysis program? In that
caes, you really should be carefully following LSTC's installation
instructions, which will tell you how to ensure that the program's
dependencies have been met.

If it turns out that LSTC's instructions include "You are responsible
for making sure that libg2c.so.0 exists on your system", then we have a
slightly different [sub-]problem.

Some googling reveals that libg2c is "gcc's internal replacement for
libf2c, the FORTRAN to C wrapper's library." I'm guessing that those
words will be familiar to you -- that you've done the same googling I
did, and found this post:

http://lists.debian.org/debian-amd64/2005/03/msg00650.html
That poster said:

   libg2c is part of gcc. Actually, it is gcc's internal replacement for
   libf2c, the FORTRAN to C wrapper's library. What you need is a FORTRAN
   enabled gcc package:
     ./configure --enable-languages=c,c++,f77

Er, slow down. I see what you did, but you need to stop and consider
what you're doing and why.

The debian.org poster was saying that libg2c is a library that gets
built when you _build gcc_ with FORTRAN-support enabled at that time
(as an option while building gcc). You should be aware that gcc is
a _suite_ of compilers, not (any longer) just a C compiler, which is
why it's now been retroactively renamed the GNU Compiler Collection
(instead of its original name of GNU C Compiler).

_But_, that having been said, the f2c component of gcc (the FORTRAN-to-C
preprocessor component) apparently isn't always present in standard gcc
installations. The Debian poster was saying that, if you don't already
have libg2c available on your system, even though you have gcc installed
(and do you, by the way?), then it might be because the guys who
compiled your distribution's version of gcc didn't bother to compile
_it_ with the necessary FORTRAN-support compilation options.

The Debian poster assumed he was talking to someone who knew the basics
of how (and why, and when) to locate a codebase in source code form and
recompile it. One hopes that his advice was appropriate in the original
context. It's less clear that it is appropriate in yours.

For one thing, gcc is very close to the top of my list of things _not_
to tell a newcomer to compile. It is a very large and very complex
codebase, which goes through some unusual steps to complete the compile.
(It compiles the compiler, then uses that to compile itself again, and
then compares the two new compilers to make sure they're the same.)

Compiling gcc takes a really, really long time and a tremendous amount
of RAM and disk space. Believe me, you will not want to do that unless
you really must. And you would not wisely take on that task until after
you know your way around Linux/Unix systems and know the basics of
compiling things, well. You would start with something really small,
like the source code to GNU tar, and make sure you understand what's
going on, there, before moving on to larger and more complex things.
You'd want to have at least a vague notion about autoconf (and thus
about files called "configure" that you find in the top level of an
unpacked source code tarball), about GNU make, about system libraries
and the dynamic loader (ldd) + its cache + its configuration file.

Not to put too fine a point on it, you would _definitely_ not seek to
compile gcc at a time when you type "./configure" _outside_ the source
tree you're seeking to compile, and are mystified when the system
responds "bash: ./configure: No such file or directory".

That error message means:

1. bash (your shell) is saying something to you. ("bash:")
2. It's saying that it looked around in the current directory
   for the file you asked it to run, "configure", and didn't see
   any such file.

What's the big picture, on that? The Debian poster was saying: "Look,
if you really need libg2c (which is an optionally-compiled part of gcc),
and _if_ you already have gcc installed, then obviously your problem
is that your gcc was compiled without FORTRAN support. Therefore,
_if_ that's your situation, and you care enough to go through the
_serious_ pain of compiling gcc, then

1. fetch the source code to whatever version of gcc you wish to
    compile.
2. untar that source code.
3. cd into the unpacked archive's top-level directory.
4. _Then_, type "./configure --enable-languages=c,c++,f77"
5. (Impliedly,) then carry out whatever other steps the gcc
    source tarball's README specifies, to complete that process.

The obvious question, in any event, is: _Is there a better way_
to install a FORTRAN-enabled set of gcc files on your SUSE 9.2 system?

Damn straight there is! I googled for

   SUSE package libg2c

and it popped out immediately: You're going to want to install a
binary RPM package -- a package _right on_ your SUSE Linux 9.2
installation CDs, called "gcc-g77", which furnishes
/usr/lib/libg2c.so.0, among other things.

> I don't really want to redownload & burn my SuSE 9.2 DVD...

Well, now you now one reason why you made a big error in _not_ keeping
around a copy of your installation media. Silly user.

Googling on

   SUSE package libg2c 9.2

finds, as an early hit:

http://rpmfind.net/linux/RPM/suse/9.2/i386/suse/x86_64/gcc-g77-32bit-9.2-200412202043.x86_64.html

...but there's a gotcha....

In downloading RPMs, you face the pitfall of making _very_ sure that you
are getting RPMs for the correct CPU architecture. SUSE installs
slightly different sets of RPMs, depending on whether your CPU is x86_64
(i.e., either AMD64 or EM64T) on the one hand, or generic x86 (which is
dubbed "i386") on the other. Here are all of RPMfind.net's RPMs for
SUSE's 9.2 release -- listing all the architectures:

http://rpmfind.net/linux/RPM/suse/9.2/i386/

And, whoops, rpmfind.net itself has a broken link in place of its 9.2
tree. But there's a link to a "local mirror" at
ftp://fr2.rpmfind.net/linux/SuSE-Linux/i386/9.2/

Digging down, we find directories that have actual binary RPMs:

ftp://fr2.rpmfind.net/linux/SuSE-Linux/i386/9.2/suse/i586/
ftp://fr2.rpmfind.net/linux/SuSE-Linux/i386/9.2/suse/x86_64/

Which of those you should visit will depend on what sort of architecture
you have -- and, guess what? You didn't bother to mention that.

In the i586 tree:
  gcc-g77-3.3.4-11.i586.rpm

In the x86_64 tree:
  gcc-g77-3.3.4-11.x86_64.rpm <= Used for 32-bit compilation.
  gcc-g77-32bit-9.2-200412202043.x86_64.rpm <= Used for 64-bit compilation.

I'll bet that installing whichever set of those is appropriate for your
architecture will fix your problem -- _without_ having to spend hours
and hours recompiling gcc.

And: "rpm -Uvh something.rpm" will do the trick (carried out as the
root user), given that something.rpm has been downloaded to the current
directory.

And^2: You might as well redownload and burn your SUSE 9.2 DVD.

You're welcome. 

-- 
Cheers,                   Mark Moraes: "Usenet is not a right."
Rick Moen            Edward Vielmetti: "Usenet is a right, a left, a jab,
rick@linuxmafia.com                     and a sharp uppercut to the jaw.
                                        The postman hits!  You have new mail."

Relevant Pages

  • Re: HPGCC Questions ladies and gentlemen!!!
    ... No matter how you slice it in order to compile a C program you need to know ... it took a few hours just to get gcc running in my computer ... of the students that used an ide in the c++ class I took a few years ago. ... so why not use a data inspector if it's available? ...
    (comp.sys.hp48)
  • Re: How to generate a md5 hash?
    ... I made it exactly as described but when I try to compile I dont got ... Note that you have to tell GCC about all the source files you ... It's also a good idea to enable warnings: ... Finally, the source code in that RFC is a little archaic, ...
    (comp.lang.c)
  • Re: Just starting out in C
    ... was based on the ANSI standard as it was being developed. ... Some words about gcc: ... gcc provides some extensions to the language that aren't supported by ... For example, to compile the Hello, World program, use the command line ...
    (comp.lang.c)
  • Compiling source code out of the blue
    ... Now admittedly, I tend to have a phobia of this situation because I recall from my Windows days the numerous times I was given code that was supposedly "good to go", but which failed to compile for some stupid reason. ... Anyway, pretending I have faith for a moment in receiving a program's source code to compile to yield an executable binary, I'd just like to ask how best to compile it "in release mode" using gcc. ...
    (comp.lang.c)
  • Re: Aquarius prolog so fast?
    ... Mercury cannot do all this because Mercury cannot keep track of the fact ... you need this capability quite rarely, ... Why not the alternative GCC back-end, ... While Mercury can compile to the internal data structures of the gcc backend, ...
    (comp.lang.prolog)