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: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 0F9271F453 for ; Fri, 18 Jan 2019 14:12:03 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=kNB90EOmu2y1e/A5 /qjdwPqRs16sNlzQe9orWWCL4FDpwM6WFsviD4oRvLdd5Es/7FaDkP4Z7qUe9KLz 2vUZVezEvZwAkeINyWUbu9Frl2WbnhGU7Gm8fBI9ihR5s3pJluDa/MTpEgoxbQ0I 9NbeDTL+CWJ44OxeWfbnRmQwdBw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=5UY0sm40BwL3ibG7QT0bIC dTI/M=; b=QIKvgFRjFbUx9JkbdccwFE7ggUj2mOegfzngzgzRbfDXlRgOkiZrEW rXLmYwKFYgKR/yeMossmWiUHH0M143ItTHQbFyiNcwWnA236U1uRrNxAz2CkkcRk FRVsFeZBN08jDAWezlvtDJPR89YqIU+IHM3Q9QqoPABryB4ozF0Dk= Received: (qmail 36430 invoked by alias); 18 Jan 2019 14:12:00 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 35857 invoked by uid 89); 18 Jan 2019 14:12:00 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qt1-f194.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9G8iVzIXuNNfJMjCS6QsT9jPiqNLCR4tHiWmEU1Dn4o=; b=gnQBIUoCAEX1LdEZ/DeGsSRwApWj3Bm9AjQpxz2KYRmUrpJ76+ZjeeSLYyvqX0kivO r4WnvEFmTwU0wXJZ7GDJnpniVUBX0V/eKpliIEitUcjDZPNdD5xmBX0F8aC0+E5U8Vdy wz6cn1hRmgG+cz1vPpklZ7ovi+vjNSpZ/kdNQ= To: libc-alpha@sourceware.org References: <20190117212928.GA17305@thunder.hadrons.org> <875zumqnun.fsf@oldenburg2.str.redhat.com> From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Re: [PATCH] Deprecate 32-bit off_t support Message-ID: <8b4497e7-4c27-b1dc-6887-d62c8b4a1b16@linaro.org> Date: Fri, 18 Jan 2019 12:11:52 -0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <875zumqnun.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 18/01/2019 08:09, Florian Weimer wrote: > * Guillem Jover: > >> Hi! >> >> On Fri, 2019-01-04 at 13:39:59 +0100, Florian Weimer wrote: >>> diff --git a/NEWS b/NEWS >>> index cc20102fda..2f601c6217 100644 >>> --- a/NEWS >>> +++ b/NEWS >>> @@ -85,6 +85,15 @@ Deprecated and removed features, and other changes affecting compatibility: >>> as all functions that call vscanf, vfscanf, or vsscanf are annotated with >>> __attribute__ ((format (scanf, ...))). >>> >>> +* A future release of glibc will use a 64-bit off_t type on all >>> + architectures (as currently available with -D_FILE_OFFSET_BITS=64 on >>> + 32-bit architectures). Building new applications with >>> + -D_FILE_OFFSET_BITS=32 will no longer be supported. The off64_t type and >>> + the 64-bit function aliases (such as fstat64) will remain available under >>> + the appropriate feature test macros. In preparation, libraries should >>> + stop using off_t in public header files, and use off64_t (or a fixed-width >>> + type such as int64_t or uint64_t) instead. >>> + >>> Changes to build and runtime requirements: >>> >>> * Python 3.4 or later is required to build the GNU C Library. >> >> While I'm fully behind further pushing to get software to switch to >> build (and work) with LFS (that's the reason I proposed the below lintian >> tag some time ago), it feels that something like the above might still be >> a bit too aggressive? :/ >> >> For example in Debian that would probably imply not being able to >> upgrade to such glibc until at least all shared libraries and packages >> supporting and implementing plugins listed at >> >> >> >> have been transitioned (with either SONAME bumps, or package renames >> with Breaks/Conflicts), or determined to not affect their ABI. Please >> notice at the top, the comment about that page only having a truncated >> view of the affected packages; in addition there might be other packages >> not being currently detected. > > What's interesting is what is *not* in this list. As far as I can see, > the non-cross binutils is missing, and so are Berkeley DB and > parts/versions of of LLVM. What's common among them is that they > install public header files under /usr/include which use off_t in the > API. So these ABIs already assume that client code is compiled with > -D_FILE_OFFSET_BITS=64. > > Sure, some corner cases may break when we change the default, but other > things will magically start working. I think it is worth a try. It is not clear to me if packages are being built without LFS due wrong configure/build options, lack of support from distro built system, or explicit disabling in package build (due either lack of testing or ABI limitation). Also, it is really questionable to have a system with mixed LFS support for libraries specially the one that might export off_t in its API. My impression is, for system consistency, have all libraries with explicit LFS support and handle outliers as why the program/libraries is building *without* non-LFS support (not the other way around).