mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Colin Cross <ccross@google.com>
Cc: musl@lists.openwall.com, Markus Wichmann <nullplan@gmx.net>
Subject: Re: [musl] Revisiting LFS64 removal
Date: Fri, 30 Sep 2022 15:29:30 -0400	[thread overview]
Message-ID: <20220930192929.GD29905@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAMbhsRQ7TOOQkpfonGPzCUT8pmiCSfg1z8G+L-1m5V3jEmEEGQ@mail.gmail.com>

On Fri, Sep 30, 2022 at 10:35:32AM -0700, Colin Cross wrote:
> On Fri, Sep 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 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.
> 
> 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

Thanks for running these checks! Do you know where we go about
reporting this to the rust folks? I'd like to get the process started
on getting this fixed asap so hopefully the impact on users is low by
the time it gets to them.

Rich

  parent reply	other threads:[~2022-09-30 19:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26  1:03 Rich Felker
2022-09-26 16:03 ` Markus Wichmann
2022-09-26 16:47   ` Rich Felker
2022-09-26 22:04 ` Rich Felker
2022-09-27  9:09   ` Gabriel Ravier
2022-09-27 12:20     ` Rich Felker
2022-09-27 19:03       ` Rich Felker
2022-09-27 19:08         ` Rich Felker
2022-09-29 23:07           ` Rich Felker
2022-09-30  2:44             ` Markus Wichmann
2022-09-30 12:57               ` Rich Felker
2022-09-30 17:35                 ` Colin Cross
2022-09-30 18:13                   ` enh
2022-09-30 19:26                     ` Rich Felker
2022-09-30 23:03                       ` enh
2022-09-30 19:29                   ` Rich Felker [this message]
2022-09-30 19:41                     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220930192929.GD29905@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=ccross@google.com \
    --cc=musl@lists.openwall.com \
    --cc=nullplan@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).