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=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24387 invoked from network); 30 Sep 2022 18:13:56 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 30 Sep 2022 18:13:56 -0000 Received: (qmail 18178 invoked by uid 550); 30 Sep 2022 18:13:53 -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 18139 invoked from network); 30 Sep 2022 18:13:52 -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=TR1jUmCugiwLauZWvZ28v1hPijBNm8aRvePbH+gPMZ0=; b=q88h7xH45htDnGTuKcdgvAUyxHBuOcs7J3Q8bsmsXXih8qy3iGinxGTvjkGoqxnQtW arIOxDuvX2d7NwxrKuWd9hWn97QU+DHvY8RU+UxMLQO9CKVhpcxaPM9/93MsB2kbfTlz VkakCH2xSq3dXk+oH2vodlcSDsiEOlVCjbVe+jHXi80cUaOeqTk/ir0Ntx5JrCCbAX0D qySdojYg95Nvs/Rli2wWL8qa48gyzpr3nWXITUHJ8GTbtXJatW/JdvPsV1+LVo7Y5y3J ASsZ4oFmsF9shfHg23CBcD9Hx6MkUgFLizdO8Pvn8mGK/lYzvlkpc8Yb8k9hMT192TzS C6VQ== 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=TR1jUmCugiwLauZWvZ28v1hPijBNm8aRvePbH+gPMZ0=; b=JwliWbuhxiwy5W9omXbbIUFere/Elvq0AnYz2kDnu3x6kMX6gn516zJDgbI5tfM16a z8Kn4SpDKi1aqlmfEBgOeif2FT/d/LM08BSo/6HSfe9Baj1ZeXFLgDte61DyvJGLbISP HVHUvT6T6fMlXICYn1XjpN6g+JCFlSoH515XBEIrKd++sQkcVMo0efHLX2WU7e8OQ7bJ 8R5TZmCTCin7QusXMbQcSwBVf5GdZb0ucZTS+caU+ZtXBkxRomYC/2nCAh+vGrMJW3me Z54rUKFmYtD90oqojipZ9DN09e5n/XrLDodO5OP+YUUQoeHomjjGIIgGy/pzcD/eTHAh CG7g== X-Gm-Message-State: ACrzQf3ieWGCCukCxJRcFKf9sWw60tzNORTIh2VKJe56I5ChKmJXloz5 iBzvZNjgRmTUlD7QT4EUZl0GtLGZ2h5Vk+AQzprE9tEM/l0= X-Google-Smtp-Source: AMsMyM4/vsi4cml9OxCzKZYV0adN5oTp8f+fdrN4hX6UHyjKCrz4GZvIsFkh+AozEfMbLFOHwo2Gs7Std8xYb1oMKGQ= X-Received: by 2002:a05:6512:2286:b0:49e:eb:ea19 with SMTP id f6-20020a056512228600b0049e00ebea19mr3869354lfu.645.1664561619782; Fri, 30 Sep 2022 11:13:39 -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: From: enh Date: Fri, 30 Sep 2022 11:13:28 -0700 Message-ID: To: musl@lists.openwall.com Cc: Markus Wichmann Content-Type: multipart/alternative; boundary="0000000000000e826f05e9e8f4dd" Subject: Re: [musl] Revisiting LFS64 removal --0000000000000e826f05e9e8f4dd Content-Type: text/plain; charset="UTF-8" On Fri, Sep 30, 2022 at 10:36 AM Colin Cross wrote: > 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. > ...and the fact that we can't flip the switch globally for the OS build without risking subtle ABI changes. but maybe these days we could recognize such things (via the .lsdump stuff)? maybe it's time to try? (we have similar issues with code that's also built for macOS, which never had the *64 functions or off64_t, so there might be some low-hanging fruit by extending those `#if __APPLE__` hacks -- that are basically just `#define off64_t off_t` etc -- to apply to musl too...) > There are a few usages in third party code, but I think most of them > just need a tweak in the configs Android uses. > --0000000000000e826f05e9e8f4dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Sep 30, 2022 at 10:36 AM Coli= n Cross <ccross@google.com> = wrote:
On Fri, S= ep 30, 2022 at 5:58 AM Rich Felker <dalias@libc.org> 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 bu= t 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_LARGEFILE6= 4_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 replacemen= t,
> > 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.=C2=A0 The first patch is=
mostly fine, but causes link failures in rust modules.=C2=A0 I think that&#= 39;s
due to the upstream rust libc assuming the presence of fstat64, etc.:
https= ://cs.android.com/android/platform/superproject/+/master:external/rust/crat= es/libc/src/unix/linux_like/mod.rs;l=3D1665;drc=3Db38fde0ab980c7d79f0a55aec= 1b7121022a38257

The second patch causes 680 unique errors.=C2=A0 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.

...and the fact that we can't flip th= e switch globally for the OS build without risking subtle ABI changes. but = maybe these days we could recognize such things (via the .lsdump stuff)? ma= ybe it's time to try?

(we have similar issues = with code that's also built for macOS, which never had the *64 function= s or off64_t, so there might be some low-hanging fruit by extending those `= #if __APPLE__` hacks -- that are basically just `#define off64_t off_t` etc= -- to apply to musl too...)
=C2=A0
There are a few usages in third party code, but I think most of them
just need a tweak in the configs Android uses.

=C2=A0
--0000000000000e826f05e9e8f4dd--