From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19526 invoked by alias); 1 Dec 2013 16:24:59 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 19510 invoked by uid 89); 1 Dec 2013 16:24:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-lb0-f176.google.com Received: from Unknown (HELO mail-lb0-f176.google.com) (209.85.217.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 01 Dec 2013 16:24:56 +0000 Received: by mail-lb0-f176.google.com with SMTP id x18so7843637lbi.7 for ; Sun, 01 Dec 2013 08:24:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.29.147 with SMTP id k19mr40590182lbh.9.1385915086926; Sun, 01 Dec 2013 08:24:46 -0800 (PST) Received: by 10.112.132.168 with HTTP; Sun, 1 Dec 2013 08:24:46 -0800 (PST) In-Reply-To: <529A8B18.1070008@warwick.ac.uk> References: <52993F21.2060700@warwick.ac.uk> <52994B57.4030003@warwick.ac.uk> <529A8B18.1070008@warwick.ac.uk> Date: Sun, 01 Dec 2013 16:24:00 -0000 Message-ID: Subject: Re: I have no ideas about an error involving CXXABI From: Jonathan Wakely To: Alec Teal Cc: gcc-help Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00005.txt.bz2 [Please don't top-post on this list] On 1 December 2013 01:04, Alec Teal 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?