* I have no ideas about an error involving CXXABI @ 2013-11-30 1:56 Alec Teal 2013-11-30 2:20 ` Jonathan Wakely 0 siblings, 1 reply; 8+ messages in thread From: Alec Teal @ 2013-11-30 1:56 UTC (permalink / raw) To: gcc-help 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: I have no ideas about an error involving CXXABI 2013-11-30 1:56 I have no ideas about an error involving CXXABI Alec Teal @ 2013-11-30 2:20 ` Jonathan Wakely 2013-11-30 4:19 ` Alec Teal 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Wakely @ 2013-11-30 2:20 UTC (permalink / raw) To: Alec Teal; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: I have no ideas about an error involving CXXABI 2013-11-30 2:20 ` Jonathan Wakely @ 2013-11-30 4:19 ` Alec Teal 2013-11-30 17:51 ` Jonathan Wakely 0 siblings, 1 reply; 8+ messages in thread From: Alec Teal @ 2013-11-30 4:19 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: I have no ideas about an error involving CXXABI 2013-11-30 4:19 ` Alec Teal @ 2013-11-30 17:51 ` Jonathan Wakely 2013-12-01 1:04 ` Alec Teal 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Wakely @ 2013-11-30 17:51 UTC (permalink / raw) To: Alec Teal; +Cc: gcc-help 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. > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: I have no ideas about an error involving CXXABI 2013-11-30 17:51 ` Jonathan Wakely @ 2013-12-01 1:04 ` Alec Teal 2013-12-01 16:24 ` Jonathan Wakely 0 siblings, 1 reply; 8+ messages in thread From: Alec Teal @ 2013-12-01 1:04 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help 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. >> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: I have no ideas about an error involving CXXABI 2013-12-01 1:04 ` Alec Teal @ 2013-12-01 16:24 ` Jonathan Wakely 2013-12-03 16:45 ` Alec Teal 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Wakely @ 2013-12-01 16:24 UTC (permalink / raw) To: Alec Teal; +Cc: gcc-help [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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: I have no ideas about an error involving CXXABI 2013-12-01 16:24 ` Jonathan Wakely @ 2013-12-03 16:45 ` Alec Teal 2013-12-04 13:21 ` Jonathan Wakely 0 siblings, 1 reply; 8+ messages in thread From: Alec Teal @ 2013-12-03 16:45 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help 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) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: I have no ideas about an error involving CXXABI 2013-12-03 16:45 ` Alec Teal @ 2013-12-04 13:21 ` Jonathan Wakely 0 siblings, 0 replies; 8+ messages in thread From: Jonathan Wakely @ 2013-12-04 13:21 UTC (permalink / raw) To: Alec Teal; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-12-04 13:21 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-30 1:56 I have no ideas about an error involving CXXABI Alec Teal 2013-11-30 2:20 ` Jonathan Wakely 2013-11-30 4:19 ` Alec Teal 2013-11-30 17:51 ` Jonathan Wakely 2013-12-01 1:04 ` Alec Teal 2013-12-01 16:24 ` Jonathan Wakely 2013-12-03 16:45 ` Alec Teal 2013-12-04 13:21 ` Jonathan Wakely
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).