I have no ideas about an error involving CXXABI

I have no ideas about an error involving CXXABI

[Alec Teal]

The error is:

./A.out: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 
`CXXABI_1.3.8' not found (required by ./A.out)

I can reproduce it on

gcc --version
gcc (GCC) 4.9.0 20131023 (experimental)

and one built yesterday, and today.

But I gcc 4.7.3 is fine.

Here's how you can:
-----------------------------------------------------
class B {
public:
     B() {}
     ~B() {}
};

template<class T>
class A {
public:
     A(int i,int j) {
         data = new T[i*j];
     }
     ~A() { delete[] data; }
protected:
     T* data;
};

int main(int,char**) {
     A<int>     a(5,5);

     A<B>    b(5,5);

     return 0;
}
----------------------------------------------

It is okay with A<B> but hates A<int> (I discovered it with doubles)

Other data:

ldconfig -p | grep libstdc
     libstdc++.so.6 (libc6,x86-64) => 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
     libstdc++.so.6 (libc6) => /usr/lib/i386-linux-gnu/libstdc++.so.6
     libstdc++.so.5 (libc6) => /usr/lib/i386-linux-gnu/libstdc++.so.5

I honestly don't know what's wrong.


Alec

Re: I have no ideas about an error involving CXXABI

[Jonathan Wakely]

On 30 November 2013 01:28, Alec Teal wrote:
> The error is:
>
> ./A.out: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8'
> not found (required by ./A.out)

It means the version of libstdc++.so.6 being found by the dynamic
linker at run-time is older than the version of libstdc++.so.6 that
was used at link-time.  That usually happens because you use a new
version of GCC to compile and link, but do not tell the dynamic linker
how to find the libraries from the new GCC.

See http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
and the section of the manual it links to.

Re: I have no ideas about an error involving CXXABI

[Alec Teal]

Thanks Jonathan.

Already found that, I'm sending this because I am entirely out of ideas.

Alec

On 30/11/13 01:55, Jonathan Wakely wrote:
> On 30 November 2013 01:28, Alec Teal wrote:
>> The error is:
>>
>> ./A.out: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8'
>> not found (required by ./A.out)
> It means the version of libstdc++.so.6 being found by the dynamic
> linker at run-time is older than the version of libstdc++.so.6 that
> was used at link-time.  That usually happens because you use a new
> version of GCC to compile and link, but do not tell the dynamic linker
> how to find the libraries from the new GCC.
>
> See http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
> and the section of the manual it links to.

Re: I have no ideas about an error involving CXXABI

[Jonathan Wakely]

On Saturday, 30 November 2013, Alec Teal  wrote:
> Thanks Jonathan.
>
> Already found that, I'm sending this because I am entirely out of ideas.

But that's the solution.

Where is your GCC 4.9.0 installed?
(My guess is not /usr)

What does the /usr/lib/x86_64-linux-gnu/libstdc++.so.6 symlink point to?
(my guess is the libstdc++.so.6.0.17 from your GCC 4.7.3, which is too
old to use for binaries built with GCC 4.9.0, which uses
libstdc++.so.6.0.20)


> Alec
>
> On 30/11/13 01:55, Jonathan Wakely wrote:
>>
>> On 30 November 2013 01:28, Alec Teal wrote:
>>>
>>> The error is:
>>>
>>> ./A.out: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8'
>>> not found (required by ./A.out)
>>
>> It means the version of libstdc++.so.6 being found by the dynamic
>> linker at run-time is older than the version of libstdc++.so.6 that
>> was used at link-time.  That usually happens because you use a new
>> version of GCC to compile and link, but do not tell the dynamic linker
>> how to find the libraries from the new GCC.
>>
>> See http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
>> and the section of the manual it links to.
>
>

Re: I have no ideas about an error involving CXXABI

[Alec Teal]

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. 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)

Alec


On 30/11/13 10:23, Jonathan Wakely wrote:
> On Saturday, 30 November 2013, Alec Teal  wrote:
>> Thanks Jonathan.
>>
>> Already found that, I'm sending this because I am entirely out of ideas.
> But that's the solution.
>
> Where is your GCC 4.9.0 installed?
> (My guess is not /usr)
>
> What does the /usr/lib/x86_64-linux-gnu/libstdc++.so.6 symlink point to?
> (my guess is the libstdc++.so.6.0.17 from your GCC 4.7.3, which is too
> old to use for binaries built with GCC 4.9.0, which uses
> libstdc++.so.6.0.20)
>
>
>> Alec
>>
>> On 30/11/13 01:55, Jonathan Wakely wrote:
>>> On 30 November 2013 01:28, Alec Teal wrote:
>>>> The error is:
>>>>
>>>> ./A.out: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8'
>>>> not found (required by ./A.out)
>>> It means the version of libstdc++.so.6 being found by the dynamic
>>> linker at run-time is older than the version of libstdc++.so.6 that
>>> was used at link-time.  That usually happens because you use a new
>>> version of GCC to compile and link, but do not tell the dynamic linker
>>> how to find the libraries from the new GCC.
>>>
>>> See http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
>>> and the section of the manual it links to.
>>

Re: I have no ideas about an error involving CXXABI

[Jonathan Wakely]

[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?

Re: 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)

Re: I have no ideas about an error involving CXXABI

[Jonathan Wakely]

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.