Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMKF1srYQ3Abxtj6gni64eLnGW15OK77OwOePTQhdFJx--icfg@mail.gmail.com>
Date: Mon, 27 Jan 2025 11:17:04 -0800
From: Khem Raj <raj.khem@...il.com>
To: musl@...ts.openwall.com
Cc: enh <enh@...gle.com>, Aditya Kumar <appujee@...gle.com>
Subject: Re: fts.h

On Mon, Jan 27, 2025 at 7:25 AM Rich Felker <dalias@...c.org> wrote:
>
> On Thu, Jan 23, 2025 at 01:54:41PM -0500, enh wrote:
> > https://wiki.musl-libc.org/faq says "If glibc bug 15838 is fixed by
> > adding an fts64 interface in glibc, we could consider supporting it
> > with a matching ABI in musl, but it seems more likely that glibc will
> > just deprecate this interface", but that bug _was_ fixed in 2015 for
> > glibc 2.23...
>
> I wonder when that text was written. While we could certainly consider
> it, lack of any apparent need so far suggests that it wouldn't meet
> the modern criteria for inclusion in musl.
>
> The main motivation I could potentially see flipping this is if there
> are a significant number of programs shipping their own (e.g. gnulib?)
> versions of fts, that would save significant code-duplication disk
> space (or get better behavior of some sort) if using a shared copy in
> libc.

In yocto, we use the fts library https://github.com/pullmoll/musl-fts
and checked core layer and meta-openembedded layer which is 3000+ packages
following 8 are depending on it explicitly.
pmdk, fluentbit, libabigail, dracut, overlayfs-tools, libcgroup, ltp elfutils

>
> Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.