From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97235 invoked by alias); 19 Jan 2017 20:38:07 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 97217 invoked by uid 89); 19 Jan 2017 20:38:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=mingw-w64, mingww64, won=e2, sk:fxcoude?= X-HELO: mail-wm0-f66.google.com Received: from mail-wm0-f66.google.com (HELO mail-wm0-f66.google.com) (74.125.82.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Jan 2017 20:38:05 +0000 Received: by mail-wm0-f66.google.com with SMTP id d140so1721122wmd.2 for ; Thu, 19 Jan 2017 12:38:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tc9bGI6z4t2bxFzDaZ4o5QBe/WBkkIBBX9+igDiwUkg=; b=tuA23aj51lHbR6GzJstXcQSQG5FT/VGvq+Xd70JoPSKCpM0xBya3n64wT/fCrUiDEC HsREY7k+HIkT4ls2c6krDbo8t4is5y2cFsKYbUA8FHS5ZxdqAIkNrfuFa8ReQWqN4BrK LwRnBEA0TxFOFhZintb3VOQEMAQpK96QgceRotNuVn82nwUlE/9JRdRJj1MD9GKgSv52 KNFXMb/tIxhmx4WtkGk1J+M5shux3gKro5BDcMrAtLadr5pBs61/J9ShXmK5PphT6Ilw 43J6GlZo40Gjd2p7984Ulh+Ah25gScD+HdELKM06hskYTKMGs4QHzaUGOmoTUeW3o5ap igew== X-Gm-Message-State: AIkVDXK+ShN02wiPSzRJWx0iaVFMSCWQzGN8G7EfxWWSS9ZaNHe9FSHMR2WfvJmk1QH3mw== X-Received: by 10.28.58.204 with SMTP id h195mr382479wma.116.1484858283216; Thu, 19 Jan 2017 12:38:03 -0800 (PST) Received: from [192.168.1.80] (5-49-98-41.hfc.dyn.abo.bbox.fr. [5.49.98.41]) by smtp.gmail.com with ESMTPSA id w197sm728782wmd.11.2017.01.19.12.38.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 12:38:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Multilib seems to fail for mingw-w64 build From: FX In-Reply-To: <88EC942B-E26B-476A-8241-117D69CC5A3F@gmail.com> Date: Thu, 19 Jan 2017 20:38:00 -0000 Cc: ktietz70@googlemail.com, 10walls@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <88EC942B-E26B-476A-8241-117D69CC5A3F@gmail.com> To: GCC Development X-SW-Source: 2017-01/txt/msg00170.txt.bz2 Hi, Help from a build maintainer needed :) I am trying to find why mingw-w64 won=E2=80=99t build as a GCC cross-compil= er with multilib (see full report below). It fails in building 32-bit libgc= c, because we=E2=80=99re passing it the wrong flags. From toplevel configur= e, we have: FLAGS_FOR_TARGET=3D$FLAGS_FOR_TARGET#' -L${prefix}/${target}/lib -L${pr= efix}/mingw/lib -isystem ${prefix}/${target}/include -isystem ${prefix}/min= gw/include=E2=80=99 However this is wrong: these flags should be dependent on whether we link 3= 2 or 64-bit, as 32-bit libraries are in ${prefix}/${target}/lib32, and 64-b= it libraries are in ${prefix}/${target}/lib. Anyone knows how we can make toplevel configure aware of the multilib natur= e of the system? Cheers, FX PS: The gcc specs know how to deal with that, as we have in the target conf= iguration file: $ cat gcc/config/i386/t-mingw-w64=20 MULTILIB_OPTIONS =3D m64/m32 MULTILIB_DIRNAMES =3D 64 32 MULTILIB_OSDIRNAMES =3D ../lib ../lib32 > Le 13 janv. 2017 =C3=A0 13:25, FX a =C3=A9crit : >=20 > Hi, >=20 > I am trying to compile a multilib-enabled GCC cross-compiler targetting m= ingw-w64. I have the mingw-w64 headers installed, the CRT built for both 32= - and 64-bit, and installed (with libs in $ROOT/x86_64-w64-mingw32/lib32 an= d $ROOT/x86_64-w64-mingw32/lib respectively). >=20 > Building the compiler itself work, but it fails to link 32-bit libgcc bec= ause it is not looking for the mingw libraries in the right place. The conf= igure line is: >=20 > ../gcc-src/configure --prefix=3D$ROOT --with-sysroot=3D$ROOT --disable= -werror --target=3Dx86_64-w64-mingw32 --enable-targets=3Dall >=20 > but when it gets to link 32-bit libgcc_s_sjlj-1.dll, it fails because it = is searching for 32-bit libmingwthrd.a in the 64-bit library directory: >=20 > /Users/fx/devel/mingw-w64/cross/x86_64-w64-mingw32/bin/ld: skipping in= compatible /Users/fx/devel/mingw-w64/cross/x86_64-w64-mingw32/lib/libmingwt= hrd.a when searching for -lmingwthrd >=20 > The reason behind that is simply that, when building 32-bit libgcc, the w= rong flags are passed to xgcc: >=20 > -L$ROOT/x86_64-w64-mingw32/lib -L$ROOT/mingw/lib -isystem $ROOT/x86_64= -w64-mingw32/include -isystem $ROOT/mingw/include -B$ROOT/x86_64-w64-mingw3= 2/bin/ -B$ROOT/x86_64-w64-mingw32/lib/ -isystem $ROOT/x86_64-w64-mingw32/in= clude -isystem $ROOT/x86_64-w64-mingw32/sys-include >=20 > These flags all refer to lib instead of lib32. >=20 > I can reproduce the problem with both GCC trunk and GCC 6.3.0. Have I mis= sed a configuration flag? Otherwise it seems like a bug in the multilib set= up, because the target configuration file seems correct: >=20 > $ cat gcc/config/i386/t-mingw-w64 > MULTILIB_OPTIONS =3D m64/m32 > MULTILIB_DIRNAMES =3D 64 32 > MULTILIB_OSDIRNAMES =3D ../lib ../lib32 >=20 >=20 > Any help in debugging this would be appreciated. >=20 > Thanks, > FX >=20