From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24910 invoked by alias); 3 Mar 2008 22:04:39 -0000 Received: (qmail 24898 invoked by uid 22791); 3 Mar 2008 22:04:38 -0000 X-Spam-Check-By: sourceware.org Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.126.183) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Mar 2008 22:04:08 +0000 Received: from kiwi.kjas.de (e178035074.adsl.alicedsl.de [85.178.35.74]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1JWIlQ2QxK-00008w; Mon, 03 Mar 2008 23:04:04 +0100 Received: by kiwi.kjas.de (Postfix, from userid 1000) id F3F6930498; Mon, 3 Mar 2008 23:04:04 +0100 (CET) Date: Mon, 03 Mar 2008 22:04:00 -0000 From: tp@fonz.de To: gcc-help@gcc.gnu.org Subject: libstdc++.so depends on libstdc++.so Message-ID: <20080303220404.GF21579@kiwi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i 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 X-SW-Source: 2008-03/txt/msg00022.txt.bz2 Hi, I'm cross-compiling gcc (with c++ enabled) to run on an arm target. Overall it works well, except: $ arm-unknown-linux-uclibc-readelf -d libstdc++.so.6.0.8 ... 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000e (SONAME) Library soname: [libstdc++.so.6] 0x0000000f (RPATH) Library rpath: [/home/.../arm-unknown-linux-uclibc/lib] The resulting libstdc++ depends on libstdc++ and has an rpath into the cross-tools directory. I've had the same with a glibc-based toolchain and with gcc 3.4, 4.1 and 4.2. Comments in the configure scripts and Makefiles indicate that libstdc++ is not to be linked with target-g++, because that includes -lstdc++. But it's exactly doing that. I haven't found a way to make it do the right thing, except dirty sed'ding various libtool and configure scripts. Another annoyance appears when libiconv is installed in the target sysroot. If gcc's configure detects iconv.h there, the target-sysroot/include path ends up in CPPFLAGS in gcc/Makefile, which in turn is used to build gcc/build/gen* - which of course fails (mixing glibc host headers and uclibc target headers). None of --without-iconv-prefix, --with-iconv-prefix=/target-sysroot or --with-iconv-prefix=/usr helped. Sed'ding gcc/Makefile (remove CPPFLAGS from BUILD_CFLAGS) helps. Thanks in advance for explanations on how this should really work, Tobias