From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,PDS_RDNS_DYNAMIC_FP, RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 966A71F670 for ; Sun, 10 Oct 2021 13:34:53 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8386E385841F for ; Sun, 10 Oct 2021 13:34:52 +0000 (GMT) Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 3D1D43858D28 for ; Sun, 10 Oct 2021 13:34:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D1D43858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de Received: from [172.17.203.2] (port=44525 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mZYyN-0005Nv-Fz; Sun, 10 Oct 2021 13:34:39 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.94.2) (envelope-from ) id 1mZYyN-0006IE-3a; Sun, 10 Oct 2021 15:34:39 +0200 From: Florian Weimer To: Stafford Horne Subject: Re: [PATCH] NEWS: Mention libpthread, libdl, libutil, libanl integration References: <871r7roomm.fsf@oldenburg.str.redhat.com> <87o87y9yta.fsf@mid.deneb.enyo.de> Date: Sun, 10 Oct 2021 15:34:39 +0200 In-Reply-To: (Stafford Horne's message of "Sun, 10 Oct 2021 09:45:31 +0900") Message-ID: <87fst90zrk.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Stafford Horne via Libc-alpha Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" * Stafford Horne: >> I think we should change the makefiles so that we still keep building >> libutil.a, but not the shared object, so that it's not necessary to >> change build systems too much. Similar for the other shared objects >> that are now empty. I'm open to other suggestions, though. > > That seems to make sense, it would be nice if there was a way to have a > deprecated warning when an app tries to link in libutil etc. This would > allow for project to clean up their makefiles to avoid unneeded linking. We can eventually add such a warning, but I think it's premature. The empty .a file does not leave any trace at all at run time. And we have to keep some of these libraries indefinitely anyway because POSIX requires that certain -l options work. Empty .a files are the easiest way to achieve that.