From: Darryl Cook (dlc@cs.appstate.edu)
Date: Mon Jun 24 2002 - 08:28:29 EDT
Thanks to the following for responses. It appears that all will work just depends
on which method you prefer. I think the easiest fix is to set LD_LIBRARY_PATH.
It seems that 3.x was changed due to the way they want to handle libraries in the
future. Libraries will be dynamically linked rather than static linked as in the
past. This apparently will make executables smaller and somewhat quicker as I
understand it. Ill include several fixes for your viewing pleasure :-)
I did try compiling with --disable-shared but still had to set LD_LIBRARY_PATH.
One note: If you use standard location of /usr/local some have said it will work
as expected. I install in /usr/local/gcc/version so I can have a couple of
versions running at a time.
Original question:
> > Im trying to get gcc-3.1 to install on both 4.0f and 5.1. They both
> > compile fine but when you do something like g++ t.C and run the a.out
> > file you the following error:
> >
> > a.out: /sbin/loader: Fatal Error: cannot map libstdc++.so
> >
> > I compiled it with configure --prefix=pathname
> > make bootstrap
> > make install
> >
> > Anyone seen this before? 2.95.3 was compiled the same way and it runs
> > fine.
>
Sheila Hollenbaugh wrote:
> The problem is that in previous versions of gcc the location of the libraries
> was known to gcc, somehow this utility has been lost. To get around this you
> can either link the libraries to a standard location (this is what we do, link
> them into /usr/lib) or you can add the location of the libraries to the
> LD_LIBRARY_PATH of all the users or train the users to do it themselves. There
> may be a way to tell gcc the location of the libraries during configuration or
> compilation, but I have not found it. If you discover that kind of a solution
> I would be interested in knowing what it is.
Versions 3.x of gcc perform dynamic linking (at runtime) rather than
create a full-linked executable (at compile time). If your gcc
libraries are not in the set of paths normally searched by the
runtime loader (as mine are not), you must compile the programs with
an extra option
-rpath /path/to/gcc/library/directory
This information will be saved somehow within a.out. When you
execute a.out, the run-time loader performs the final linking before
actual execution.
Dynamic linking has been a feature of Solaris and Linux for a few
years, but they specify the run-time library search paths slightly
differently. The idea is to make executable files smaller and to
allow them to use newer versions of libraries without recompilation.
An alternative action for you is to specify static linking (i.e. the
traditional way of creating a fully-linked executable file). I am
afraid that I do not know off the top of my head what options one
specifies to do that.
Regards,
Eric Sisson
Daryl, make sure the lib directory for gcc is in the the path. I tend
to install into "non-standard" paths and the symlink to /usr/local.
When I ran gcc/g++ from the non-standard directory without the symlinks
in place, I saw the same problem with the compiled program. I then set
LD_LIBRARY_PATH to point to the <gcc-install-path>/lib and then it
worked. After sym-linking the installed gcc/g++ stuff into user local I
didn't have to set LD_LIBRARY_PATH anymore.
hth,
\@matthias
Yes, I think I know the problem. Default on 2.95.3 was static binaries,
but on 3.1 it's shared, meaning you need libstdc++.so, or recompile with
--disable-shared.
/daniel
Point LD_LIBRARY_PATH at wherever you installed libstdc++. It would
be found automatically with the default configure prefix, /usr/local/
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:44 EDT