I don't think most (if not all) reporters can provide the exact
version of bionic they are on, though you are welcome to ask on the
github issue I linked. Quite a few reporters were with 32-bit Android
7.1.1 I think.
I myself am with 64-bit Android 8.0.0 (Not an AOSP build but a Sony
stock ROM). I
It's looking like Glibc will add a renameat2 function
that is incompatible with Gnulib renameat2; see:
https://sourceware.org/ml/libc-alpha/2018-07/msg00064.html
To help avoid future confusion, rename renameat2 to something else.
Use the name 'renameatu', as the Gnulib function is close to the
Glib
Tom Yan wrote:
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blobdiff;f=lib/stdio-impl.h;h=393ef0cf58d013ec18cfcbb2ee120c4d1df7e028;hp=7a0ac4d50b70c5ad3d3b63d7f3274ba5d6df43a3;hb=e7fb52b3a5ddffe1bba848e4966159868b6951f0;hpb=be18f9170e1989b601a08aada31438cca87cffdd
>
> The definition of fp_
Tom Yan wrote:
Since the newly introduced definition of fp_ in stdio-impl.h is found
to be causing segfaults on quite some (if not most/all) 32-bit Android
builds, we patch it (hence 8.30"-1") to avoid the definition (on all
platforms).
With what patch, exactly?
On Wed, 4 Jul 2018 at 04:22, Paul Eggert wrote:
>
> Thanks. That discussion talks about "coreutils 8.30-1"; what's that and where
> is
> its source code?
GNU coreutils 8.30. GNU coreutils 8.29 uses a pre-e7fb52b3 snapshot of
gnulib, while 8.30 uses a post-e7fb52b3 snapshot of it.
> I see this p
Tom Yan wrote:
See more discussion here:https://github.com/termux/termux-packages/issues/2603
Thanks. That discussion talks about "coreutils 8.30-1"; what's that and where is
its source code?
I see this patch:
https://github.com/termux/termux-packages/commit/86af1159d0d487368aab2494904e89b8
Hi all,
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blobdiff;f=lib/stdio-impl.h;h=393ef0cf58d013ec18cfcbb2ee120c4d1df7e028;hp=7a0ac4d50b70c5ad3d3b63d7f3274ba5d6df43a3;hb=e7fb52b3a5ddffe1bba848e4966159868b6951f0;hpb=be18f9170e1989b601a08aada31438cca87cffdd
The definition of fp_ is causing s
Florian Weimer wrote:
Surely that's a gnulib bug because the main reason for the RENAME_NOREPLACE
variant renameat2 was to avoid exactly that race (or the other race where the
file exists under both the old and new path).
No, it's intended behavior, not a bug. GNU mv uses renameat2 with
RENAM
