From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29451 invoked by alias); 3 Dec 2013 16:45:18 -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 29442 invoked by uid 89); 3 Dec 2013 16:45:17 -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,RDNS_NONE,SPF_NEUTRAL,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: emea01-db3-obe.outbound.protection.outlook.com Received: from Unknown (HELO emea01-db3-obe.outbound.protection.outlook.com) (213.199.154.77) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 03 Dec 2013 16:45:15 +0000 Received: from AMSPRD0111HT001.eurprd01.prod.exchangelabs.com (10.242.75.162) by DB3PR01MB266.eurprd01.prod.exchangelabs.com (10.141.4.17) with Microsoft SMTP Server (TLS) id 15.0.800.7; Tue, 3 Dec 2013 16:45:05 +0000 Received: from [172.31.21.26] (137.205.238.182) by pod51002.outlook.com (10.242.75.162) with Microsoft SMTP Server (TLS) id 14.16.383.1; Tue, 3 Dec 2013 16:45:05 +0000 Message-ID: <529E0A8F.3070703@warwick.ac.uk> Date: Tue, 03 Dec 2013 16:45:00 -0000 From: Alec Teal User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jonathan Wakely CC: gcc-help Subject: Re: I have no ideas about an error involving CXXABI References: <52993F21.2060700@warwick.ac.uk> <52994B57.4030003@warwick.ac.uk> <529A8B18.1070008@warwick.ac.uk> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Forefront-PRVS: 0049B3F387 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(189002)(199002)(51704005)(24454002)(479174003)(36756003)(74662001)(74502001)(47446002)(74482001)(76796001)(76786001)(54316002)(81342001)(56776001)(85852002)(23756003)(80022001)(65806001)(19580405001)(81542001)(49866001)(65956001)(83506001)(46102001)(47736001)(76482001)(74706001)(69226001)(19580395003)(50466002)(64126003)(74876001)(79102001)(66066001)(4396001)(59896001)(54356001)(81816001)(53806001)(63696002)(47976001)(74366001)(83072001)(87936001)(51856001)(33656001)(77982001)(81686001)(80976001)(80316001)(83322001)(50986001)(31966008)(85306002)(47776003)(59766001)(90146001)(56816005);DIR:OUT;SFP:;SCL:1;SRVR:DB3PR01MB266;H:AMSPRD0111HT001.eurprd01.prod.exchangelabs.com;CLIP:137.205.238.182;FPR:;RD:InfoNoRecords;MX:1;A:1;LANG:en; X-OriginatorOrg: warwick.ac.uk X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00022.txt.bz2 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 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)