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-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 1EDCD1F4B4 for ; Thu, 1 Oct 2020 20:24:36 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 307B5398600B; Thu, 1 Oct 2020 20:24:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 307B5398600B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1601583875; bh=30V4ggBT0CSztGBmEkvt5YusbSaobrsuHfvX/2/wXN4=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=K5yxvCy8GYcq07qGxlDvaWEtwME+sS3PARAiwMwRKzHToBK5ZIEp7yL+ygjrfX4RQ KspTFXMXngIL5FwOQzXzfwer8K2H+GYZw2fPf8CIh0aEjn2ykyUtQQay3W0Sc8sIiP 6enWHx+GocD1K+Rnrw4x9+c+hLGIN0L3DJzJUFG8= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 7676D398600B for ; Thu, 1 Oct 2020 20:24:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7676D398600B Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-331-JN6SIecfOvip-tfCkHBZ3A-1; Thu, 01 Oct 2020 16:24:31 -0400 X-MC-Unique: JN6SIecfOvip-tfCkHBZ3A-1 Received: by mail-qt1-f199.google.com with SMTP id u6so4594926qte.8 for ; Thu, 01 Oct 2020 13:24:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=30V4ggBT0CSztGBmEkvt5YusbSaobrsuHfvX/2/wXN4=; b=VB7IxtKC/4qRxWNkCf2aRahcRq73s7YD+YuL7OkJwqvIQhgmw/s164ky+mFQ7bTPTb mNwK1RHVpGZFR+OhS3mPbYxVXLgNS9hb05I+y3f4GwX+sJuCyF+cpTVhTOBlMtB79XwD B8IjPxyaodWhcMWSPFOTRNFluuepjvy6IuxEpPsoR1Fs27XK8kXz6Lnwhg826jJr73Dm 8CVCH5E4MH+VZD5CDFjGrQRdYpR8REIf4mqsCyXsvUjLcYc4Fmp8A5s1hafyFWb32Y63 ATx0knahbX6MNUy1p8ID/XbPPWaauYiDOpVxgWMQ3gES4G0wzIRcJOJ7AEG7AQkt1G9t YlWg== X-Gm-Message-State: AOAM533x9a2V6wE0V8tHRgX0qlKhhROOntD3gAcO7SJFXappLbncW50f uzJ93aJ26jJQbZUa3XsjaYNsy4WKzUNdNKP1+AY41PFqDRs8B+g9pCyM5FXGIQD0ALliyP9T7Wb wDJhs1LMrXkWrErBHUse0 X-Received: by 2002:ac8:2f6d:: with SMTP id k42mr2285232qta.115.1601583870675; Thu, 01 Oct 2020 13:24:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwv+cQznWgMCnFJWSXy4RQ7s9EbtkASLMeSLmtXGS93azDuOjaLsxtQDwpReQnqv5SQ0qUs3g== X-Received: by 2002:ac8:2f6d:: with SMTP id k42mr2285217qta.115.1601583870435; Thu, 01 Oct 2020 13:24:30 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id 8sm7818853qkd.47.2020.10.01.13.24.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2020 13:24:29 -0700 (PDT) Subject: Re: [PATCH 01/28] elf: Do not search HWCAP subdirectories in statically linked binaries To: Adhemerval Zanella , libc-alpha@sourceware.org References: <75fdede6bc2db8a3638c1402855b2c5245f4b545.1601569371.git.fweimer@redhat.com> <95b87318-0def-df24-d05d-1360f9857e9d@linaro.org> <1818e0ce-25da-a7a0-aaca-475b15874e8c@linaro.org> Organization: Red Hat Message-ID: <0c038109-32ac-5a69-d3c0-525f4111ced6@redhat.com> Date: Thu, 1 Oct 2020 16:24:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <1818e0ce-25da-a7a0-aaca-475b15874e8c@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: , From: Carlos O'Donell via Libc-alpha Reply-To: Carlos O'Donell Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 10/1/20 2:29 PM, Adhemerval Zanella wrote: > > > On 01/10/2020 15:24, Carlos O'Donell wrote: >> On 10/1/20 2:22 PM, Adhemerval Zanella via Libc-alpha wrote: >>> >>> >>> On 01/10/2020 13:31, Florian Weimer via Libc-alpha wrote: >>>> This functionality does not seem to be useful since static dlopen >>>> is mostly used for iconv/character set conversion and NSS support. >>>> gconv modules are loaded with full paths anyway, so that the >>>> HWCAP subdirectory logic does not apply. >>> >>> This change looks reasonable, although it makes the semantic of >>> statically linked programs slight different than dynamic one regarding >>> dlopen. >> >> I think this is OK. >> >> dlopen from statically linked programs is deprecated, the only uses >> should be internal to glibc in NSS And iconv. >> >> We really really want: >> >> * Just a statically linked program that has no external deps. >> >> * Just a dynamically linked program can support dlopen. >> >> This half-way inbetween support we have has serious consequences, >> and is the reason I supported us deprecating dlopen from static >> binaries. Users should not be allowed to shoot themselves in >> the foot. >> >> $0.02. >> > > I agree, usually on discussion about static linking with glibc users > get perplexed why shared libraries are being loaded under the hood > and usually this is a deal breaker on most usercases (another one > is the minimum kernel requirement). Fixing the dlopen case requires splitting the interface at the NSS boundary (as Florian suggested?) and calling out from the static binary to some kind of 'getent'-like binary, perhaps even getent itself in compat cases. The minimum kernel requirement is much easier to explain. We have a minimum requirement. I find users get that when it's explained clearly. -- Cheers, Carlos.