From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18311 invoked by alias); 22 Feb 2007 08:58:39 -0000 Received: (qmail 18275 invoked by uid 48); 22 Feb 2007 08:58:25 -0000 Date: Thu, 22 Feb 2007 08:58:00 -0000 Message-ID: <20070222085825.18274.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/5291] Bad reference to build directory in libstdc++.la In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "peb at mppmu dot mpg dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-02/txt/msg02546.txt.bz2 ------- Comment #18 from peb at mppmu dot mpg dot de 2007-02-22 08:58 ------- I have tried to analyze the cause of the -L flags passed to libtool when linking libsupc++ and libstdc++ and found these two: (1) explicit flags in the top-level RAW_CXX_FOR_TARGET passed as CXX to the libstdc++ and libjava modules, and (2) flags implicitly added by the GCC-modified "libtool --tag CXX --mode=link" for all directories in the compiler search path. This part is easily corrected by instead using "--tag CC" when linking libraries. I'd like to try to fix all this, but in order to do so I need some additional info. As far as I can see there are in principle three ways to build libstdc++: (A) as part of building GCC (with language c++), (B) independently with a prebuilt g++, or (C) independently with a non-GCC compiler. I think there is an obvious way to handle issue (1) above in case (A), but cases (B) and in particular (C) may pose additional problems. Question: are the possibilities (B) and (C) still viable? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291