On 01/12/13 16:24, Jonathan Wakely wrote:
[Please don't top-post on this list]
On 1 December 2013 01:04, Alec Teal <a.teal@xxxxxxxxxxxxx> wrote:
You're right Jonathan (I didn't doubt you really)
ls /usr/lib/x86_64-linux-gnu/ -l | grep libstdc
lrwxrwxrwx 1 root root 19 May 10 2013 libstdc++.so.6 ->
libstdc++.so.6.0.16
-rw-r--r-- 1 root root 962656 Apr 16 2012 libstdc++.so.6.0.16
I've looked at that page and I didn't think that this could happen.
What "this" are you talking about?
Your problem is failure to find the right libstdc++.so at run-time.
That's exactly what that page (and the one it links to in the manual)
explain how to solve. Why would we write that documentation if the
problem couldn't happen?
This
means I know less than the installation process than I thought I did. Rather
than blindly following that link can you please explain what actually
happens? (Though I am not a child if you want to withhold the answer but
give me the explanation I'd still appreciate that)
I don't know what exactly you're asking, particularly if it isn't
already covered by the link I gave.
When you installed GCC 4.9.0 it put the new libstdc++.so somewhere. I
don't know where, because you didn't confirm where you'd installed it
(but I'm still betting it's not in /usr)
When you use GCC 4.9.0 to link your program you create a dependency on
symbols in the new libstdc++.
When you try to run your program the dynamic linker doesn't know how
to find the newer libstdc++.
This is all explained in the link I gave you:
"This doesn't mean that the shared library isn't installed, only that
the dynamic linker can't find it. When a dynamically-linked executable
is run the linker finds and loads the required shared libraries by
searching a pre-configured list of directories. If the directory where
you've installed libstdc++ is not in this list then the libraries
won't be found."
It also explains how to solve the problem. I'm not going to type out
another explanation or paste in more information that is already in
the docs. What isn't clear?
A lot of things.
**Quick fix:
LD_LIBRARY_PATH=/usr/local/lib64/:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
** (found before finishing this email)
Where has the new libstd++ actually gone? My LD_LIBRARY_PATH is empty,
this magical prefix doesn't exist. (I'm guessing from ${prefix} that it
is some list of things?) Why doesn't make fix this for me? Why does the
one that came with the system get special treatment? I would have
thought that the install target would have installed the standard
libraries too.
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.
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
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? Why does it install there, why does the directory even
exist if things have to be made to manually search it?
Alec
(make install-target-libstdc++-v3 has a name that suggests it'll install
libstdc++v3)
