On Dec 3, 2013 4:45 PM, "Alec Teal" wrote:
>
>
> **Quick fix:
> LD_LIBRARY_PATH=/usr/local/lib64/:$LD_LIBRARY_PATH
> export LD_LIBRARY_PATH
> ** (found before finishing this email)
Yes, that's what it said to do in the docs I keep telling you to read!
(although it could do with an update for 64-bit libs installed by multilib GCC.)
> Where has the new libstd++ actually gone?
Wherever you installed the new GCC.
> My LD_LIBRARY_PATH is empty,
GCC doesn't alter it, that's your job.
> this magical prefix doesn't exist. (I'm guessing from ${prefix} that it is some list of things?)
No, it's a placeholder (using shell variable syntax) for the prefix
where you installed GCC.
In the libstdc++ manual that's referred to as "destdir".
The documentation assumes (maybe incorrectly) you are familiar with
using the shell and the conventions of Unix software installed with
configure and make commands. I'll update the FAQ to be explicit about
what ${prefix} refers to.
> Why doesn't make fix this for me?
It's your responsibility. Make does not alter your shell environment,
that would be bad manners, and cause havoc if you don't want the new
libraries in your library path.
So instead the installation process prints out the instructions you
need, and we document those instructions in the libstdc++ manual and
FAQ.
> Why does the one that came with the system get special treatment?
Because it's special! It's the one your whole system relies on, and
because it installed the libraries in a system directory that is
automatically included in the dynamic linker's search path.
Your distro ensures that packages installed as part of the system can
be found. It doesn't do that for software you install in other
locations, that's your job, not GCC's and not Make's.
The dynamic linker does not automatically look in arbitrary
directories for libraries that may or may not have been installed by
users who may or may not know what they're doing.
That is how GNU/Linux works.
Your question is like asking why /usr/bin is in your $PATH but
/home/Fred/some/arbitrary/path/bin isn't. Because Unix.
> I would have thought that the install target would have installed the standard libraries too.
It did. Read the bloody link again and pay attention this time.
I'll quote it *again*:
"This doesn't mean that the shared library isn't installed, only that
the dynamic linker can't find it."
> Linking that page was also annoying because of course I've found and read that, as I explained in my first email I'm here on a public mailing list confessing that I cannot fix this - in the hope of getting it fixed.
And the page has the answer.
You asked exactly the question that page answers. It's a frequently
asked question, probably the most frequently asked. The obvious
response is to point you to the answer (answering FAQs is annoying
too). We weren't to know you'd read the answer but don't understand
it.
If you had said you'd read it and what parts of it you don't
understand maybe you would have saved some wasted time.
> Yes I've also looked at where it says "Finding dynamic or shared libraries".
>
> The closest I have come is to finding Jonathan saying something elsewhere. It's really frustrating because I feel no closer to solving this problem that seems easy from what I've read.
>
> /usr/local/include/c++/4.9.0/ contains the headers (it is called include)
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/ contains some object files and libgcc
> /usr/local/share/gcc-4.9.0/ contains something related to Python.
>
> ls -l /usr/local/lib64/ | grep stdc
> -rw-r--r-- 1 root root 16344112 Dec 3 16:28 libstdc++.a
> -rwxr-xr-x 1 root root 965 Dec 3 16:28 libstdc++.la
> lrwxrwxrwx 1 root root 19 Dec 3 16:28 libstdc++.so -> libstdc++.so.6.0.19
> lrwxrwxrwx 1 root root 19 Dec 3 16:28 libstdc++.so.6 -> libstdc++.so.6.0.19
> -rwxr-xr-x 1 root root 6644991 Dec 3 16:28 libstdc++.so.6.0.19
> -rw-r--r-- 1 root root 2313 Dec 3 16:28 libstdc++.so.6.0.19-gdb.py
Those are the libraries you're looking for. Why do you think they're
not installed?
So at last we know that you installed with prefix=/usr/local (probably
because that's the default and you didn't change it.)
> Which is mentioned in various blocks from Make's output (like:
>
> ----------------------------------------------------------------------
> Libraries have been installed in:
> /usr/local/lib/../lib32
>
> If you ever happen to want to link against installed libraries
> in a given directory, LIBDIR, you must either use libtool, and
> specify the full pathname of the library, or use the `-LLIBDIR'
> flag during linking and do at least one of the following:
> - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
> during execution
> - add LIBDIR to the `LD_RUN_PATH' environment variable
> during linking
> - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
> - have your system administrator add LIBDIR to `/etc/ld.so.conf'
>
> See any operating system documentation about shared libraries for
> more information, such as the ld(1) and ld.so(8) manual pages.
> ----------------------------------------------------------------------
>
> )
>
> Is it these?
Yes.
That info refers to the 32-bit libs. Earlier there will be similar
output referring to the 64-bit libs in /usr/local/lib64
> Why does it install there,
That's how GNU/Linux works.
When you configured GCC you told it (maybe implicitly) to install to
/usr/local, so the libraries go in a sub-directory of that prefix. See
http://gcc.gnu.org/install/configure.html
> why does the directory even exist if things have to be made to manually search it?
I don't understand the question.
> Alec
>
> (make install-target-libstdc++-v3 has a name that suggests it'll install libstdc++v3)
It's already installed. That is run as part of "make install".
Aside: since you're installing to /usr/local it looks as though you're
building and installing as root. That's a good way to trash your
system if you don't understand what you're doing.
