I have no ideas about an error involving CXXABI

[Alec Teal]

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@warwick.ac.uk> 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)