From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) by sourceware.org (Postfix) with ESMTPS id BCB02385E83A; Tue, 28 Jul 2020 18:57:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BCB02385E83A Received: by mail-il1-x144.google.com with SMTP id j9so13764002ilc.11; Tue, 28 Jul 2020 11:57:53 -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=4+nKfrFLDTIel3r3cOgoyIIZrBPoiVsHamMpIFHBpsc=; b=GQ7c96AOb1KX6p28yudcUQSHzM0ZR5YjqhMpQQCvfh03Hx68TpX9bOWJlgsFe/9W7x 6Q/pZ8+GlwEVaqdghnxd9KksATeZu5sdBzXRKXMrrK7OKoPeLATf1op1BG3yTdTFfz6U JKQ2IimcdSEbYuYzomsGgGcDLV/Kk6HbAi9WmFURxoKyifcHWF26wv9+m6MznNLpZfo4 YXWvXzGxttSdUEsn9n2lpRILowgqodskFh+zHh7FQPbFky/hMkLpR24QvbFWV451G1a+ Q+NSL53ctf3AqV54sRHrM1L45Znl9kd+9uhiJHQNQ1ye5QPAop6XpoeXa7vPSk4iMvSL Ur0Q== X-Gm-Message-State: AOAM533aq8UPJ+ztGJd3ez+ARWdsIYvPxzwjLF9oaMWIpg4SWcrfmzNW h5e7tlYsQqXYgilvZSjcBzeksTqjIDvZgYpE2l8= X-Google-Smtp-Source: ABdhPJyq6wgqIFxE9r1HLAKBl4yW8C/7qRQ4RkUYhXuh93+WOq4PlmbFZ89qUlA5iFaKUsPeUr3TNQzZE9Zgjj+OAZg= X-Received: by 2002:a92:bf0c:: with SMTP id z12mr29465050ilh.151.1595962673289; Tue, 28 Jul 2020 11:57:53 -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> <0421b2c2-01b4-cf84-855f-24478ade0754@simark.ca> <68099cb1-522d-5451-3d77-4827e6e3d880@simark.ca> In-Reply-To: <68099cb1-522d-5451-3d77-4827e6e3d880@simark.ca> From: "H.J. Lu" Date: Tue, 28 Jul 2020 11:57:17 -0700 Message-ID: Subject: Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works To: Simon Marchi Cc: Andreas Schwab , "H.J. Lu via Binutils" , Aaron Merey , GCC Patches , Tom Tromey , GDB Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 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 18:57:54 -0000 On Tue, Jul 28, 2020 at 11:47 AM Simon Marchi wrote: > > On 2020-07-28 2:31 p.m., H.J. Lu wrote: > >>> Unlike gdb, binutils should have as few external depecies as possible. > >>> debuginfod brings in some so many external depecies. > >> > >> I'm not a binutils maintainer, so that's not my role to decide about that > >> tradeoff... but we are talking about having an optional (only needed when > >> enabling support for libdebuginfod) *build* dependency on a quite standard > >> tool. That's not very demanding. > >> > >> If you don't want to deal with libdebuginfod, you can also just build with > >> --without-debuginfod. > > > > My binutils script had been working fine until pkg.m4 was added > > Ok but... that doesn't mean anything. I think we made it quite clear that the > issue is with your build environment, not the build system (pkg.m4). Binutils configure script is supposed to detect if a feature is usable. In my perspective, pkg.m4 failed on my build environment. > >Can it be moved to gdb directory? > > It can, but I don't think it would be a good idea. It would just be confusing > for binutils and GDB to both use libdebuginfod but use different methods of > finding it. Somebody building binutils + GDB with libdebuginfod support against > a libdebuginfod in a non-default location would have to specify the location of > the library in two different ways. > > Simon -- H.J.