From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by sourceware.org (Postfix) with ESMTPS id 4B391384C005; Tue, 28 Jul 2020 16:08:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4B391384C005 Received: by mail-il1-x143.google.com with SMTP id y18so8221193ilp.10; Tue, 28 Jul 2020 09:08:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=93o/2xMY4NPc9K90gu/Q04fMNw6bWUs97NmPsuXyZO0=; b=Gl/1T5AWQmS/N5OpSu5Uge/c4awa5M9Ne9CXHtc3WkbUpmSmFoVXUPeAKlOlVwZgj4 vvDZF20TT8PlZlRJfpslDBEdv7qwVURBfccQyJBxit4OlVVYI6EaPakGCEHYDz1hjVU2 4LgY5ldQD84y3yYYvuzL4K1yaq19cydEyUJN+JK4oeWVjgBBmGKAASdZNjcqoep7U4WX ax2ZMFkLmaG+ysCp2KcSm8ujrqvEYLXz4vRxD3OBRupyY2QZ3XfI8/ZhOUGOSrq4+Yes 88X5xRzrxz+2QTc83iw6cpcfgO+v4+OEZA4hyeC01raB0H1k+cwDcxe6BrORKaEjaWW1 s3TQ== X-Gm-Message-State: AOAM530mjGroqmmo2WUcgIk4Aopxao8USMmQ8HHHc5NWEjYcKvEix18R NshzhbCWLZK8oR+88+sEYprR6YOV5/dSLU6QaYw= X-Google-Smtp-Source: ABdhPJyv0Q7IXn0dVkXXCAt41B/aKhOFxAB3vu/AUM/W+7uYYMJKCgI02hqmQq7eiRo8qQcs8rfWbbqRZOclI+9tuak= X-Received: by 2002:a05:6e02:e89:: with SMTP id t9mr26365981ilj.292.1595952502814; Tue, 28 Jul 2020 09:08:22 -0700 (PDT) MIME-Version: 1.0 References: <20200502022903.175852-1-amerey@redhat.com> <996bd0f9-cec5-119c-19ea-b127cf1bb95d@simark.ca> <87r1svyche.fsf@igel.home> <3209078a-429a-4be7-b151-93c3f4a53655@simark.ca> In-Reply-To: <3209078a-429a-4be7-b151-93c3f4a53655@simark.ca> From: "H.J. Lu" Date: Tue, 28 Jul 2020 09:07:46 -0700 Message-ID: Subject: Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works To: Simon Marchi Cc: GCC Patches , "H.J. Lu via Binutils" , Aaron Merey , Andreas Schwab , Tom Tromey , GDB Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 16:08:24 -0000 On Tue, Jul 28, 2020 at 8:13 AM Simon Marchi wrote: > > On 2020-07-28 11:05 a.m., H.J. Lu via Gdb-patches wrote: > >> Can you clarify how this magic works, is this standard autoconf? Because I am trying this > >> on Fedora, so pretty much the same setup as you, and I don't see this behavior: > >> > >> $ /home/simark/src/binutils-gdb/configure CC="gcc -m32" CXX="g++ -m32" > >> checking build system type... x86_64-pc-linux-gnu > >> checking host system type... x86_64-pc-linux-gnu > >> checking target system type... x86_64-pc-linux-gnu > >> ... > >> > > > > I checked it again. I also passed i686-linux, not --host=, to configure. > > Ok I see, the configure line you pasted was wrapped by your email client so was not very readable. > > Doing `./configure ` looks like a deprecated way to set all build/host/target, as the > warning message it shows implies: > > configure: WARNING: you should use --build, --host, --target > > Anyway, my point still stands: the problem is you not using a pkg-config configured properly for > the cross compilation you are attempting, not pkg.m4. > > >> > >> And even if it worked, why would it set "build" to i686, it doesn't make sense. The gcc you > >> compile with, and its environment, is still x86_64, not i686. > >> > >> So *if* it works, it would be a shortcut for setting --host=i686-something, maybe. So > >> regardless of how that above works, that doesn't remove the need to configure pkg-config > >> correctly for the host system. > >> > >> If you don't want to learn about with pkg-config and deal with it, then please say "I think > >> we should not use pkg-config", and ideally give supporting points. Please don't unilaterally > >> push patches just to paper over your own problems. You just make it so that somebody will > >> need to untangle more mess later. > > > > I am OK to remove pkg.m4. > > Well I am not. I find it quite handy to avoid having to hardcode necessary CFLAGS and LDFLAGS > required to build against a library, so I think it's better to use pkg-config if the libraries > we want to use provide a .pc file. > > I propose that we revert the patch for now to go back to the pristing pkg.m4 version. > What doesn't work with my pkg.m4 change? -- H.J.