* gnulib-tool: Do not allow --gnu-make in test modes,
since they all require automake.
(func_emit_lib_Makefile_am): Don’t emit automake comment
if --gnu-make.
---
ChangeLog | 6 ++
gnulib-tool | 8 +++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
* modules/regex (Depends-on): Add langinfo.
Without this change, I had problems building an experimental
version of GNU Emacs. The symptom of the bug was a message
‘./configure: line 12726: test: =: unary operator expected’.
This was due to a line in gl_FUNC_NL_LANGINFO that invokes
‘test $HAVE_LA
Bruno Haible wrote:
I would add a placeholder for the old module name,
for a period of transition. So that users of the 'renameat2' module
are not forced to migrate in a hurry, but instead can migrate when
it is fit for their project and schedule.
In the past, we've often avoided such placehold
Carlos O'Donell wrote:
On 07/04/2018 03:35 PM, Paul Eggert wrote:
You position Gnulib's implementation as having no drawbacks
That certainly was not my intent. The Gnulib implementation has known race
conditions on platforms whose kernels don't promise atomicity. It's just that
Gnulib-usin
Florian Weimer wrote:
as Joseph pointed out, there is a different emulation strategy with a different
failure mode (use link and potentially leave behind a hard-linked file under
both names).
So far I haven't run into applications that prefer that strategy, i.e., nobody
seems using that strat
On 07/04/2018 10:13 PM, Carlos O'Donell wrote:
This is a good suggestion, and I think Florian should work on something
going into the manual to document the behaviour.
We do not have any documentation for the *at functions at present. I
find it difficult to document renameat2 without referenc
On 07/04/2018 03:35 PM, Paul Eggert wrote:
> Carlos O'Donell wrote:
>
>> If we really need another non-race-free API then gnulib can provide
>> that.
>
> We do really need it. All existing uses of renameat2-like
> functionality in GNU applications already use the non-race-free API.
> But as I see
Carlos O'Donell wrote:
If we really need another non-race-free API then gnulib can provide that.
We do really need it. All existing uses of renameat2-like functionality in GNU
applications already use the non-race-free API. But as I see it, the consensus
is to banish this functionality to Gn
On 07/04/2018 05:04 AM, Andreas Schwab wrote:
> On Jul 03 2018, Paul Eggert wrote:
>
>> 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 bot
On Thu, 2018-06-21 at 23:12 +0200, Bruno Haible wrote:
> Paul Smith wrote:
> > However, for lib/getloadavg.c and ONLY for that lib/*.c file, I
> > ALSO get duplicate rules in my root Makefile.in
>
> Does it cause an actual problem, or does it only "feel" wrong?
It causes an actual problem in that
On 07/04/2018 04:45 AM, Paul Eggert wrote:
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'
On 07/04/2018 11:04 AM, Andreas Schwab wrote:
On Jul 03 2018, Paul Eggert wrote:
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 n
Hi Paul,
> 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
Yup, by https://sourceware.org/ml/libc-alpha/2018-07/msg00039.html
it is clear that non-atomic fallback implementations
On Jul 03 2018, Paul Eggert wrote:
> 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 behavio
14 matches
Mail list logo
