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:41:47 -0400	[thread overview]
Message-ID: <20220930194147.GE29905@brightrain.aerifal.cx> (raw)
In-Reply-To: <20220930192929.GD29905@brightrain.aerifal.cx>

On Fri, Sep 30, 2022 at 03:29:30PM -0400, Rich Felker wrote:
> 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.

OK, discussion on IRC turned up the right place to file, and I've
filed it here:

https://github.com/rust-lang/libc/issues/2934

Rich

      reply	other threads:[~2022-09-30 19:42 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
2022-09-30 19:41                     ` Rich Felker [this message]

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=20220930194147.GE29905@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).