From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 03CA73858C62 for ; Mon, 28 Nov 2022 13:00:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 03CA73858C62 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wr1-x431.google.com with SMTP id q7so15778600wrr.8 for ; Mon, 28 Nov 2022 05:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=riVD4Y2fwp8J2sFyRroiVAQevxsU/3yX4JEcZY2Q9jk=; b=eQCqCiDa8xXh6TOgnsnZZ+g7CFqTiT3CTRS9yeQ6XNzq0fMK/neS5BqFFMAUzVufPv OlOfhjQyTem+rkFBjLPF/PvgrSYzPyzge1pHcAasGimGrzVfWNugKgvqvpQUF4NGgcfp pUVZH7Tr5ioCb59I4w1XUWAZXTNYVXEHLbMWmHAzxLfkfFX2FMG+9Vhbz09o4PdKF/Lq 3BdlmrOJM/R5dF9pwAhfJdLhp5bZu+RTPRf0k7cO/m1QIlf4F3GDlO+wZnhlmnqQjOvG zPm0tzlq/IW9NL6Pf/Iny5qbzmpowzJkOZc0G92+zu2FdypUKpn23AJ0VzsQl/rL+MBb EBAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=riVD4Y2fwp8J2sFyRroiVAQevxsU/3yX4JEcZY2Q9jk=; b=WXd7FjkxnRSjWgPh8RbNBfo7ahPyWvlFQ3mq1DqLUZp4kEXxMKWv6r5TnP/kI1jTbS 2no2CAc543+Drtw4sYeWPZEcOaHJQdwuvX+NVMPWAkI3uZQCi04FSWOHYFk/daUaK7WJ mxRwiXaBzENxP/+53gYxxWS/80kO53x7Lmd0vV5VnJ5JTKqASlsi2t+USznOV4VD5twM qBOzkYbHkZhhFjeiStowWYkxN2ilM/ySYzk6NvLrnMA7gjXhn31YVa4b4UGu9vLfG5Yr nMlBPCh7VDQy65GosVyzGtgULO4uHJdhWheJRyR/7Szs4jzsk5cmUDfh8W3eMQHOx+d6 7JOg== X-Gm-Message-State: ANoB5plTaS8VQ9IipX8D4jpnKwprw79+oaFPKrT8CUXlLkWoluCORSRk hko2Z30WmGc5PVAvIU4XXEHoNSVLI328sBBh X-Google-Smtp-Source: AA0mqf6lWa7D4hOQWrX8bTs2n+U+j1UZFQvk6jopxNA8S+QUCKXiFJ7alA5Us5W2JwT49pMd88R88g== X-Received: by 2002:adf:dc01:0:b0:241:b6d0:97e with SMTP id t1-20020adfdc01000000b00241b6d0097emr20680582wri.100.1669640401602; Mon, 28 Nov 2022 05:00:01 -0800 (PST) Received: from [192.168.0.201] ([212.69.42.53]) by smtp.gmail.com with ESMTPSA id r12-20020a5d494c000000b00241b6d27ef1sm10623486wrs.104.2022.11.28.05.00.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2022 05:00:01 -0800 (PST) Date: Mon, 28 Nov 2022 12:59:52 +0000 (GMT) From: "Maciej W. Rozycki" To: Eli Zaretskii cc: gdb-patches@sourceware.org Subject: Re: [PATCH 1/3] GDB: Run `pkg-config' with `--static' to pull libguile dependencies In-Reply-To: <83pmdbv55m.fsf@gnu.org> Message-ID: References: <83pmdbv55m.fsf@gnu.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 25 Nov 2022, Eli Zaretskii wrote: > > In configurations using the ELF format dynamic libguile implicitly pulls > > indirect dependencies in the link, but to satisfy static libguile they > > need to be named explicitly. These dependencies have been recorded and > > can be supplied by `pkg-config', but for that to happen the tool has to > > be invoked with the `--static' option in addition to `--libs'. Moreover > > it is recommended, at least with systems using the ELF format, to have > > indirect dependencies included with static linker invocation even where > > they all are satisfied by dynamic libraries. > > If only a static version of the Guile library is installed, how come > "pkg-config --libs" doesn't produce the list of all the dependency libraries > for static linking? Isn't that a bug in Guile installation on that system? If anything, it's a bug in Guile itself, or more likely a design issue with pkg-config. Looking at its .pc template I can see no provision for a different library arrangement depending on whether `--enable-shared' or `--disable-shared' is in effect with `configure': Libs: -L${libdir} -lguile-@GUILE_EFFECTIVE_VERSION@ @BDW_GC_LIBS@ Libs.private: @LIB_CLOCK_GETTIME@ @LIBGMP@ @LIBLTDL@ @LIBFFI_LIBS@ \ @LIBUNISTRING@ @GUILE_LIBS@ @LIBICONV@ @LIBINTL@ @LIBSOCKET@ \ @SERVENT_LIB@ @HOSTENT_LIB@ @GETADDRINFO_LIB@ @INET_NTOP_LIB@ \ @INET_PTON_LIB@ I have skimmed over the very few .pc templates I could find around on my system and they all seem to do essentially the same. For example have a look at zlib/contrib/minizip/minizip.pc.in in our very own tree. While not used by us it's taken verbatim from the upstream zlib distribution and supplied with libminizip, which has a dependency on libz. But the template has just: Libs: -L${libdir} -lminizip Libs.private: -lz i.e. it's all fixed with no `configure' processing whatsoever and there is no provision for pulling `-lz' unless `--static' has been explicitly given to `pkg-config'. But any such provision looks to me like a lot of effort for software writers, to take away which is the very purpose of pkg-config. So what I think pkg-config should do is to provide a flag for the .pc file to be set by `configure' or otherwise, which would tell pkg-config that said package has been built with no shared libraries available, via `--disable-shared' or an equivalent. In such a case pkg-config would always include Libs.private along with Libs when requested by `--libs', even if no `--static' option has been given. Which leads me to a conclusion it's an oversight in the pkg-config design that it does not provide for the static-only link scenario in a reasonable way. > > Therefore fix the issue by using the `--static' option unconditionally > > with `pkg-config', adding the dependencies required: > > I don't think I've every seen a configure script that explicitly includes > the --static switch to pkg-config. Did you? If not, how do they deal with > this issue? Almost any external library with which GDB is linked can be > installed as a static-only library, so do we need to use --static in all > pkg-config tests? I see that your proposed patch only changes the tests for > Guile and for source-highlight libraries. It seems to me that distributions universally build libraries as shared and do not provide for installing static libraries without their shared counterparts. And that people hardly ever build from sources nowadays. So it looks to me like this issue is not dealt with at all, and while we might try to fix the world outside, it could be a futile effort. And in any case it'd be long until any solution lands downstream. Then as I say indirect dependencies are best included in ELF links involving dynamic shared objects anyway, so I think using `--static' is in my opinion a reasonable solution. I think it's also needed for the `CFLAGS=-static' case too. Cf. . I haven't looked at pieces coming from outside gdb/, and I can see now that the debuginfod library isn't handled at this point (I don't know if it has any indirect dependencies). It's use here is a strong argument in favour of 3/3, so that we don't use $pkg_config and $PKG_CONFIG variables both at a time for the same thing in a single script (what a mess!). Do you find my observations a sufficient justification for my proposed change now? Thank you for your insights! Maciej