From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17596 invoked by alias); 16 Apr 2010 14:53:40 -0000 Received: (qmail 17288 invoked by uid 48); 16 Apr 2010 14:53:17 -0000 Date: Fri, 16 Apr 2010 14:53:00 -0000 Message-ID: <20100416145317.17287.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/40125] libgcc_s DLL installed in wrong directory in cross toolchain In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dougsemler at gmail dot com" 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: 2010-04/txt/msg01564.txt.bz2 ------- Comment #3 from dougsemler at gmail dot com 2010-04-16 14:53 ------- Right now in a cross environment, the target libraries, when built as DLLs, are also installed in the host's bindir, due to the -bindir flag now being passed to libtool. While this may be appropriate in a native compiler case, I don't think it's right in a cross environment. My opinion is that in a cross environment, the -bindir parameter should be $(toolexeclibdir), and not $(bindir). This will expand to exec_prefix/target/lib/MULTIOSSUBDIR or gcc's private dir/MULTISUBDIR when version-specific-runtime is specified. This places the DLLs in the same structure as their matching .dll.a files and separates the libs properly on multilib 64 bit mingw. I think, in a cross environment, libgcc_s should also follow this convention :) -- dougsemler at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dougsemler at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40125