From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 19826 invoked from network); 30 Sep 2022 17:36:01 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 30 Sep 2022 17:36:01 -0000 Received: (qmail 14009 invoked by uid 550); 30 Sep 2022 17:35:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13977 invoked from network); 30 Sep 2022 17:35:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=yl7CWCw1dMlZrIJV+aDeJRvVissQwf+uyEltiLAITtI=; b=i4W/Kgz6qOOdebW2InwM6xKN/9nRE5WIgFRR1xzjgG+rmXbw4rgHFOvhQET2AKKW9Y X4T08/6+8xpnPP/2IXQ0ffO0XILOlkBUKDa/ZiJ7BUYfrJqMkkfJxZ+nZaJb0OI9LJnd qHPXZDiHkbfcmhIfh5qTtOuq5WdBpKt3NcGX2JpIuB7zvLObUKT15FFaap0JGLP/V5n/ FFMGJlJrVs8+sG+oenUY6TUu9oizZxDcICzDngi0tUwuM6XyuMC4ELCCXFc3b92QEYFE QE7JnD1oQdk09AnFGNZod/6M7PZhQTDD6NMvUd2OEgNSjpPlmstcZPvnC5SDPaJxv2Ee bpVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=yl7CWCw1dMlZrIJV+aDeJRvVissQwf+uyEltiLAITtI=; b=28C1rOVpbjS7XCT9Wm0xVdQJegwGpMR9QWB50OaDVo7fkYnKqW5kR767rc74fxP5Lp S25pXIVp7A5yyOHeQ5ddKsbcpePrN6Nj1AIp4+YAvBhT2xGeU300fism8IwSKZkh0KSt a3K13f4F1lLEwnDaq7cErjI/6ijVwRD55KWF4Wx2p5yeh5xEAc/fwbaQVQGckCUZoMp5 7SGHuUvTuoAa9/c5e7n1o+/YXnQ3uJRnaD55Nxz0UjSdqv0Hvomlr0m1sUh/lac+JWYT z0/ANTsNcMrP3CwoDE8159zCh0jKz53Ne7QM25lBkXj7aB3YAm9BdLqh9KS3m0Dc72Lj F4jA== X-Gm-Message-State: ACrzQf1YPECyg1pPkRK1GWLBQpVEI3kg5xMr0jJtzEgQaThNgQhu8lmd HRtU71H+vFK/ZWutGLg8GluvkjHIm8fWIpuCDJ7dBd6ReeE= X-Google-Smtp-Source: AMsMyM4HEGcmHLjpltEY9zQhNd3G8/H8YBenrwrP0SbNWkdr2lMm5pSVfOxslXBgY4wMz+RGm/AzmaD1IIQVwQBhNL8= X-Received: by 2002:a05:6638:1c0b:b0:35a:26bc:88c0 with SMTP id ca11-20020a0566381c0b00b0035a26bc88c0mr5264085jab.249.1664559343946; Fri, 30 Sep 2022 10:35:43 -0700 (PDT) MIME-Version: 1.0 References: <20220926010339.GA9709@brightrain.aerifal.cx> <20220926220449.GE9709@brightrain.aerifal.cx> <20220927122005.GG9709@brightrain.aerifal.cx> <20220927190357.GH9709@brightrain.aerifal.cx> <20220927190853.GI9709@brightrain.aerifal.cx> <20220929230707.GA29905@brightrain.aerifal.cx> <20220930024447.GC2645@voyager> <20220930125754.GB29905@brightrain.aerifal.cx> In-Reply-To: <20220930125754.GB29905@brightrain.aerifal.cx> From: Colin Cross Date: Fri, 30 Sep 2022 10:35:32 -0700 Message-ID: To: musl@lists.openwall.com Cc: Markus Wichmann Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Revisiting LFS64 removal On Fri, Sep 30, 2022 at 5:58 AM Rich Felker wrote: > > On Fri, Sep 30, 2022 at 04:44:47AM +0200, Markus Wichmann wrote: > > On Thu, Sep 29, 2022 at 07:07:08PM -0400, Rich Felker wrote: > > > As an alternative, maybe we should consider leaving these but only > > > under explict _LARGEFILE64_SOURCE rather than implicitly via > > > _GNU_SOURCE for at least one release cycle. This would allow makeshift > > > fixing of any builds that break by just adding -D_LARGEFILE64_SOURCE > > > until a proper fix can be applied. > > > > > > Any preference here? > > > > > > Rich > > > > Given that nothing lasts as long as a temporary measure, I'd say it is > > That's not a given for musl, quite the opposite. I would expect it to > last at most a release cycle, possibly even to disappear before then > if distros backport the changes to their development branches early > and find and fix everything. > > > better to rip the band-aid off in one go rather than two. Besides, any > > breakage ought to be able to be dealt with by a simple replacement, > > right? > > It's a simple fix, but the question is how many such simple fixes a > distro might need to make in their packages, and that I don't know. > > If they have a trivial mechanical fix of "add something to CFLAGS" > they can do at first, that lets them build a list of affected packages > while quickly getting them all building again, then work out the right > fixes one at a time according to usual triage rather than being > swamped with these taking priority over issues with more depth. > > Rich I experimented with building all the host code in the Android tree with these two patches just to measure the damage. The first patch is mostly fine, but causes link failures in rust modules. I think that's due to the upstream rust libc assuming the presence of fstat64, etc.: https://cs.android.com/android/platform/superproject/+/master:external/rust/crates/libc/src/unix/linux_like/mod.rs;l=1665;drc=b38fde0ab980c7d79f0a55aec1b7121022a38257 The second patch causes 680 unique errors. Many of those are in Android-specific code that uses the *64 functions directly, which I think is especially common due to early bionic's poor LFS64 support. There are a few usages in third party code, but I think most of them just need a tweak in the configs Android uses.