GNU bug report logs -
#32452
26.1; gnutls_try_handshake maxes out cpu retrying when server is a bit busy
Previous Next
Reported by: Noam Postavsky <npostavs <at> gmail.com>
Date: Thu, 16 Aug 2018 12:14:01 UTC
Severity: minor
Tags: moreinfo
Found in version 26.1
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32452 in the body.
You can then email your comments to 32452 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 16 Aug 2018 12:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Noam Postavsky <npostavs <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 16 Aug 2018 12:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Severity: minor
Recently the debbugs.gnu.org server is slow to respond. I notice this
both when opening bug reports in Firefox, and from Emacs. However,
Emacs uses 100% cpu while waiting for the server. I added a message
call in gnutls_try_handshake (see patch below), and got "gnutls
non-fatal: Resource temporarily unavailable, try again. [190088 times]"
in *Messages*. This was from doing M-x gnus-read-ephemeral-bug-group,
it took 5 or 10 seconds to (eventually successfully) complete.
We should have some kind of delay to avoid sending so many useless
retries.
--- i/src/gnutls.c
+++ w/src/gnutls.c
@@ -65,6 +65,7 @@ your option) any later version.
static bool gnutls_global_initialized;
+static char const * emacs_gnutls_strerror (int err);
static void gnutls_log_function (int, const char *);
static void gnutls_log_function2 (int, const char *, const char *);
# ifdef HAVE_GNUTLS3
@@ -558,7 +559,9 @@ gnutls_try_handshake (struct Lisp_Process *proc)
}
while (ret < 0
&& gnutls_error_is_fatal (ret) == 0
- && ! non_blocking);
+ && ! non_blocking
+ && (message ("gnutls non-fatal: %s", emacs_gnutls_strerror (ret)),
+ true));
proc->gnutls_initstage = GNUTLS_STAGE_HANDSHAKE_TRIED;
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 16 Aug 2018 12:50:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> gmail.com> writes:
> I added a message call in gnutls_try_handshake (see patch below)
> + && (message ("gnutls non-fatal: %s", emacs_gnutls_strerror (ret)),
> + true));
Ah, this patch isn't needed, (setq gnutls-log-level 1) suffices:
gnutls.c: [1] (Emacs) non-fatal error: Resource temporarily unavailable, try again. [329434 times]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 16 Aug 2018 13:42:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Thu, 16 Aug 2018 08:13:40 -0400
>
> Recently the debbugs.gnu.org server is slow to respond. I notice this
> both when opening bug reports in Firefox, and from Emacs. However,
> Emacs uses 100% cpu while waiting for the server. I added a message
> call in gnutls_try_handshake (see patch below), and got "gnutls
> non-fatal: Resource temporarily unavailable, try again. [190088 times]"
> in *Messages*. This was from doing M-x gnus-read-ephemeral-bug-group,
> it took 5 or 10 seconds to (eventually successfully) complete.
Does anything change if you disable asynchronous DNS and connection
establishment?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 16 Aug 2018 14:46:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 32452 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 16 August 2018 at 09:41, Eli Zaretskii <eliz <at> gnu.org> wrote:
> Does anything change if you disable asynchronous DNS and connection
> establishment?
Um, how should I do that? The :nowait argument to open-network-stream
is already nil, if that's what you meant (see attached backtrace).
[gnutls-boot-stacktrace.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 16 Aug 2018 17:35:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Thu, 16 Aug 2018 10:45:12 -0400
> Cc: 32452 <at> debbugs.gnu.org
>
> > Does anything change if you disable asynchronous DNS and connection
> > establishment?
>
> Um, how should I do that?
Compile with HAVE_GETADDRINFO_A undefined? Although if :nowait is
nil, then I'm not sure such a compilation will change anything. But I
think it's worth trying, as at least some of the related code doesn't
seem to be disabled by :nowait being nil, if my reading of the code is
correct.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 17 Aug 2018 01:03:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Compile with HAVE_GETADDRINFO_A undefined? Although if :nowait is
> nil, then I'm not sure such a compilation will change anything. But I
> think it's worth trying, as at least some of the related code doesn't
> seem to be disabled by :nowait being nil, if my reading of the code is
> correct.
No, it doesn't seem to make a difference (though the server is answering
a bit faster at the moment, I'm only getting the 20~30k "Resource
temporarily unavailable..." messages with both HAVE_GETADDRINFO_A
defined and undefined).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 17 Aug 2018 06:00:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: 32452 <at> debbugs.gnu.org
> Date: Thu, 16 Aug 2018 21:02:29 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Compile with HAVE_GETADDRINFO_A undefined? Although if :nowait is
> > nil, then I'm not sure such a compilation will change anything. But I
> > think it's worth trying, as at least some of the related code doesn't
> > seem to be disabled by :nowait being nil, if my reading of the code is
> > correct.
>
> No, it doesn't seem to make a difference (though the server is answering
> a bit faster at the moment, I'm only getting the 20~30k "Resource
> temporarily unavailable..." messages with both HAVE_GETADDRINFO_A
> defined and undefined).
OK, so do you understand the sequence of the events well enough to
describe what happens, and explain why we get so many EAGAIN errors?
I'm not yet sure this is bug, maybe it's just how things are in this
case (modulo exerting less CPU load, something that we certainly
should try).
Also, does this happen with every server, or just with some?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 17 Aug 2018 11:56:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> OK, so do you understand the sequence of the events well enough to
> describe what happens, and explain why we get so many EAGAIN errors?
> I'm not yet sure this is bug, maybe it's just how things are in this
> case (modulo exerting less CPU load, something that we certainly
> should try).
I haven't really traced things through properly, but my current
understanding/guess is that we're using non-blocking sockets even though
we actually want blocking behaviour. So to get the blocking behaviour
we just spin in a loop.
> Also, does this happen with every server, or just with some?
debbugs.gnu.org seems to be the most extreme case (at the moment), with
other servers I see only about a hundred "Resource temporarily
unavailable" messages (I'm noticing this now because I switched on
gnutls-log-level, but it's not enough to cause a noticable CPU spike).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 17 Aug 2018 12:27:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: 32452 <at> debbugs.gnu.org
> Date: Fri, 17 Aug 2018 07:55:44 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > OK, so do you understand the sequence of the events well enough to
> > describe what happens, and explain why we get so many EAGAIN errors?
> > I'm not yet sure this is bug, maybe it's just how things are in this
> > case (modulo exerting less CPU load, something that we certainly
> > should try).
>
> I haven't really traced things through properly, but my current
> understanding/guess is that we're using non-blocking sockets even though
> we actually want blocking behaviour. So to get the blocking behaviour
> we just spin in a loop.
In which case it's fine, we just need to do something in the loop to
yield the CPU, like some nanosleep, perhaps? And maybe enlarge the
sleep period as time goes on?
> > Also, does this happen with every server, or just with some?
>
> debbugs.gnu.org seems to be the most extreme case (at the moment), with
> other servers I see only about a hundred "Resource temporarily
> unavailable" messages (I'm noticing this now because I switched on
> gnutls-log-level, but it's not enough to cause a noticable CPU spike).
debbugs is terribly slow in a browser as well, right now. But
hundreds of attempts sounds excessive to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 17 Aug 2018 22:11:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> In which case it's fine, we just need to do something in the loop to
> yield the CPU, like some nanosleep, perhaps? And maybe enlarge the
> sleep period as time goes on?
>
> debbugs is terribly slow in a browser as well, right now. But
> hundreds of attempts sounds excessive to me.
The debbugs server seems back to normal speeds now, I'm getting ~200
hits with it just like other servers. The patch below brings it down to
15~20. nanosleep isn't portable though right? Not sure what to put
instead, it seems existing wait functions in Emacs are all tied up with
threads and processes, so I don't know if it's safe to call them here.
--- i/src/gnutls.c
+++ w/src/gnutls.c
@@ -550,6 +550,8 @@ gnutls_try_handshake (struct Lisp_Process *proc)
if (non_blocking)
proc->gnutls_p = true;
+ enum { MAX_DELAY_NS = 100 * 1000 * 1000 }; // Max 100ms delay.
+ struct timespec delay = { 0, 1000 };
do
{
ret = gnutls_handshake (state);
@@ -558,7 +560,9 @@ gnutls_try_handshake (struct Lisp_Process *proc)
}
while (ret < 0
&& gnutls_error_is_fatal (ret) == 0
- && ! non_blocking);
+ && ! non_blocking
+ && (nanosleep (&delay, NULL),
+ delay.tv_nsec = min (delay.tv_nsec * 2, MAX_DELAY_NS)));
proc->gnutls_initstage = GNUTLS_STAGE_HANDSHAKE_TRIED;
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Sat, 18 Aug 2018 06:35:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: 32452 <at> debbugs.gnu.org
> Date: Fri, 17 Aug 2018 18:10:32 -0400
>
> The debbugs server seems back to normal speeds now, I'm getting ~200
> hits with it just like other servers. The patch below brings it down to
> 15~20.
Good.
> nanosleep isn't portable though right?
We could use usleep instead, it's part of Posix, AFAIK. And MinGW has
it as well, AFAICT. Sorry I didn't mention it in the first place.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Tue, 21 Aug 2018 00:54:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> nanosleep isn't portable though right?
>
> We could use usleep instead, it's part of Posix, AFAIK. And MinGW has
> it as well, AFAICT. Sorry I didn't mention it in the first place.
My usleep(3) man page says it's obsolete:
CONFORMING TO
4.3BSD, POSIX.1-2001. POSIX.1-2001 declares this function obsolete; use nanosleep(2)
instead. POSIX.1-2008 removes the specification of usleep().
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Tue, 21 Aug 2018 02:43:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: 32452 <at> debbugs.gnu.org
> Date: Mon, 20 Aug 2018 20:52:58 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> nanosleep isn't portable though right?
> >
> > We could use usleep instead, it's part of Posix, AFAIK. And MinGW has
> > it as well, AFAICT. Sorry I didn't mention it in the first place.
>
> My usleep(3) man page says it's obsolete:
Then I guess use nanosleep if it's available and usleep if it isn't?
Alternatively, we could make nanosleep fopr Windows using usleep, and
use nanosleep from Gnulib if platforms other than Windows don't have
it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Tue, 24 Sep 2019 05:40:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> gmail.com> writes:
> + enum { MAX_DELAY_NS = 100 * 1000 * 1000 }; // Max 100ms delay.
> + struct timespec delay = { 0, 1000 };
> do
> {
> ret = gnutls_handshake (state);
> @@ -558,7 +560,9 @@ gnutls_try_handshake (struct Lisp_Process *proc)
> }
> while (ret < 0
> && gnutls_error_is_fatal (ret) == 0
> - && ! non_blocking);
> + && ! non_blocking
> + && (nanosleep (&delay, NULL),
> + delay.tv_nsec = min (delay.tv_nsec * 2, MAX_DELAY_NS)));
This code has changed somewhat since the proposed patch:
while ((ret = gnutls_handshake (state)) < 0)
{
do
ret = gnutls_handshake (state);
while (ret == GNUTLS_E_INTERRUPTED);
if (0 <= ret || emacs_gnutls_handle_error (state, ret) == 0
|| non_blocking)
break;
maybe_quit ();
}
But perhaps adding some sleep here would be a good idea, anyway. On the
other hand, 100ms seems way too long -- that's a noticeable slow-down in
network set-up.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Mon, 21 Feb 2022 15:21:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Alternatively, we could make nanosleep fopr Windows using usleep, and
> use nanosleep from Gnulib if platforms other than Windows don't have
> it.
I thought I could have a look at this (i.e., adding nanosleep from
Gnulib and then implement this).
I've never done a Gnulib merge, so I just tried running
admin/merge-gnulib first to bring us up to date... and this resulted in
a vc-dir buffer that's 114 lines long and starts with:
build-aux/
edited build-aux/config.guess
edited build-aux/config.sub
edited build-aux/gitlog-to-changelog
edited build-aux/update-copyright
lib/
edited lib/acl-errno-valid.c
edited lib/acl-internal.c
edited lib/acl-internal.h
edited lib/acl.h
edited lib/acl_entries.c
[...]
edited lib/filevercmp.h
edited lib/fpending.c
edited lib/fpending.h
unregistered lib/fpurge.c
unregistered lib/freading.c
unregistered lib/freading.h
And fails with:
configure:42647: error: possibly undefined macro: gl_PREREQ_RAWMEMCHR
configure:42918: error: possibly undefined macro: gl_PREREQ_STRTOLL
autoreconf: error: /usr/bin/autoconf failed with exit status: 1
So... er... I'm guessing something's not quite right here. 🙃
Paul, do you have any advice?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Wed, 23 Feb 2022 19:46:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 32452 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2/21/22 07:20, Lars Ingebrigtsen wrote:
> Paul, do you have any advice?
I think the problem was mostly due to Gnulib's recent changing of how it
handles conditionally-generated directories like lib/alloca.h. I
installed the first attached patch to try to fix this. The second patch
is the result of running admin/merge-gnulib, and the third does a minor
cleanup of two new Gnulib files that Emacs doesn't need.
Also, I installed the fourth attached patch to port Emacs's Git hooks to
Git 2.35.1, the current Git version, as Emacs was relying on an
undocumented Git feature that Git removed. (Am I the only Emacs
developer using up-to-date Git?)
[0001-Port-to-current-Gnulib.patch (text/x-patch, attachment)]
[0002-Update-from-Gnulib-by-running-admin-merge-gnulib.patch (text/x-patch, attachment)]
[0003-Port-to-current-Gnulib-some-more.patch (text/x-patch, attachment)]
[0004-Port-pre-commit-hook-to-Git-2.35.0.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Wed, 23 Feb 2022 19:50:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> I think the problem was mostly due to Gnulib's recent changing of how
> it handles conditionally-generated directories like lib/alloca.h. I
> installed the first attached patch to try to fix this. The second
> patch is the result of running admin/merge-gnulib, and the third does
> a minor cleanup of two new Gnulib files that Emacs doesn't need.
Thanks; it seems to get a bit further now, but fails here:
Checking for autoconf (need at least version 2.65) ... ok
Your system has the required tools.
Building aclocal.m4 ...
Running 'autoreconf -fi -I m4' ...
configure.ac:6060: warning: gl_FUNC_CLOSE is m4_require'd but not m4_defun'd
m4/fclose.m4:7: gl_FUNC_FCLOSE is expanded from...
m4/gnulib-comp.m4:225: gl_INIT is expanded from...
configure.ac:6060: the top level
configure:27383: error: possibly undefined macro: gl_FUNC_CLOSE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: error: /usr/bin/autoconf failed with exit status: 1
> Also, I installed the fourth attached patch to port Emacs's Git hooks
> to Git 2.35.1, the current Git version, as Emacs was relying on an
> undocumented Git feature that Git removed. (Am I the only Emacs
> developer using up-to-date Git?)
I just use whatever is in Debian/testing, which is:
$ git --version
git version 2.34.1
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Wed, 23 Feb 2022 22:31:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 32452 <at> debbugs.gnu.org (full text, mbox):
On 2/23/22 11:48, Lars Ingebrigtsen wrote:
> it seems to get a bit further now, but fails here:
Looks like you need to fetch the latest Gnulib and/or build from
scratch, as I think I fixed those symptoms in Gnulib here:
https://lists.gnu.org/r/bug-gnulib/2022-02/index.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Wed, 23 Feb 2022 22:41:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> Looks like you need to fetch the latest Gnulib and/or build from
> scratch, as I think I fixed those symptoms in Gnulib here:
Yup, after fetching the latest Gnulib, admin/merge-gnulib seems to work
fine (i.e., changes almost nothing since you've just merged).
But it does alter this file:
* edited lib/gnulib.mk.in
Is that normal? The diff on that file starts with the following, and
there's only line deletions in the diff -- almost 1K lines deleted:
diff --git a/lib/gnulib.mk.in b/lib/gnulib.mk.in
index 6b90a80f64..25c991b961 100644
--- a/lib/gnulib.mk.in
+++ b/lib/gnulib.mk.in
@@ -170,31 +170,14 @@
MOSTLYCLEANFILES += core *.stackdump
# Start of GNU Make output.
-ALLOCA = @ALLOCA@
-ALLOCA_H = @ALLOCA_H@
-ALSA_CFLAGS = @ALSA_CFLAGS@
-ALSA_LIBS = @ALSA_LIBS@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
-APPLE_UNIVERSAL_BUILD = @APPLE_UNIVERSAL_BUILD@
AR = @AR@
-ARFLAGS = @ARFLAGS@
AUTO_DEPEND = @AUTO_DEPEND@
-AWK = @AWK@
-BITSIZEOF_PTRDIFF_T = @BITSIZEOF_PTRDIFF_T@
-BITSIZEOF_SIG_ATOMIC_T = @BITSIZEOF_SIG_ATOMIC_T@
-BITSIZEOF_SIZE_T = @BITSIZEOF_SIZE_T@
-BITSIZEOF_WCHAR_T = @BITSIZEOF_WCHAR_T@
-BITSIZEOF_WINT_T = @BITSIZEOF_WINT_T@
BLESSMAIL_TARGET = @BLESSMAIL_TARGET@
BREW = @BREW@
BUILD_DETAILS = @BUILD_DETAILS@
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 24 Feb 2022 03:10:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 32452 <at> debbugs.gnu.org (full text, mbox):
On 2/23/22 14:40, Lars Ingebrigtsen wrote:
>
> MOSTLYCLEANFILES += core *.stackdump
> # Start of GNU Make output.
> -ALLOCA = @ALLOCA@
> -ALLOCA_H = @ALLOCA_H@
That means something went wrong. It looks like you're using a mixture of
the old and new somehow. You might try removing autom4te.cache and
re-running admin/merge-gnulib.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 24 Feb 2022 08:59:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 2/23/22 14:40, Lars Ingebrigtsen wrote:
>> MOSTLYCLEANFILES += core *.stackdump
>> # Start of GNU Make output.
>> -ALLOCA = @ALLOCA@
>> -ALLOCA_H = @ALLOCA_H@
>
> That means something went wrong. It looks like you're using a mixture
> of the old and new somehow. You might try removing autom4te.cache and
> re-running admin/merge-gnulib.
The problem was that I was running admin/merge-gnulib from a fresh
checkout -- you have to run (at least) autogen.sh first. Perhaps that
should be noted in admin/notes/repo, or possibly fixed in the
merge-gnulib script?
In any case, if I do that now, I get a diff that's just a single line:
diff --git a/lib/gnulib.mk.in b/lib/gnulib.mk.in
index 6b90a80f64..3a9f5b9818 100644
--- a/lib/gnulib.mk.in
+++ b/lib/gnulib.mk.in
@@ -207,7 +207,6 @@ CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
CRYPTOLIB = @CRYPTOLIB@
CXX = @CXX@
-CXXCPP = @CXXCPP@
CXXFLAGS = @CXXFLAGS@
CYGWIN_OBJ = @CYGWIN_OBJ@
C_SWITCH_MACHINE = @C_SWITCH_MACHINE@
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 24 Feb 2022 18:21:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 32452 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2/24/22 00:57, Lars Ingebrigtsen wrote:
> The problem was that I was running admin/merge-gnulib from a fresh
> checkout -- you have to run (at least) autogen.sh first. Perhaps that
> should be noted in admin/notes/repo, or possibly fixed in the
> merge-gnulib script?
Thanks for reporting that; I installed the attached.
> In any case, if I do that now, I get a diff that's just a single line:
>
> -CXXCPP = @CXXCPP@
That's probably due to differing versions of Autoconf. It shouldn't
matter for Emacs since Emacs doesn't use CXXCPP.
It is annoying that this difference would occur on different platforms;
for now, I wouldn't worry about it (or install the change, as it'll just
be overwritten the next time I do a Gnulib update).
I use Fedora autoconf FWIW.
[0001-admin-merge-gnulib-fix-bare-checkout-Bug-32452-65.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 25 Feb 2022 02:21:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> Thanks for reporting that; I installed the attached.
Thanks.
>> In any case, if I do that now, I get a diff that's just a single line:
>> -CXXCPP = @CXXCPP@
>
> That's probably due to differing versions of Autoconf. It shouldn't
> matter for Emacs since Emacs doesn't use CXXCPP.
>
> It is annoying that this difference would occur on different
> platforms; for now, I wouldn't worry about it (or install the change,
> as it'll just be overwritten the next time I do a Gnulib update).
Right; will do.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 25 Feb 2022 02:28:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 32452 <at> debbugs.gnu.org (full text, mbox):
I tried to include the nanosleep module by adding to GNULIB_MODULES and
then doing the merge, and the set of new files looks reasonable:
./
admin/
edited admin/merge-gnulib
lib/
edited lib/gnulib.mk.in
unregistered lib/nanosleep.c
unregistered lib/sig-handler.c
unregistered lib/sig-handler.h
unregistered lib/sigaction.c
m4/
edited m4/gnulib-comp.m4
unregistered m4/nanosleep.m4
unregistered m4/sigaction.m4
But autogen.sh fails:
Running 'autoreconf -fi -I m4' ...
configure.ac:6060: warning: gl_FUNC_SELECT is m4_require'd but not m4_defun'd
m4/nanosleep.m4:14: gl_FUNC_NANOSLEEP is expanded from...
m4/gnulib-comp.m4:215: gl_INIT is expanded from...
configure.ac:6060: the top level
configure:29948: error: possibly undefined macro: gl_FUNC_SELECT
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: error: /usr/bin/autoconf failed with exit status: 1
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 25 Feb 2022 20:42:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 32452 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2/24/22 18:27, Lars Ingebrigtsen wrote:
> But autogen.sh fails:
>
> Running 'autoreconf -fi -I m4' ...
> configure.ac:6060: warning: gl_FUNC_SELECT is m4_require'd but not m4_defun'd
This is because Gnulib's 'nanosleep' module depended on the 'select'
module, but Emacs's admin/merge-gnulib avoids the 'select' module
(because Emacs relies on pselect instead and has its own MS-DOS pselect
substitute).
Gnulib's nanosleep appears to use select only for old Unixish platforms
that were relevant in 2000 but aren't practical porting targets any
more. So I installed into Gnulib the attached patch to simplify Gnulib
nanosleep by having it fall back on pselect rather than select, and to
not bother with signal handling. This should cause your addition of
nanosleep to admin/merge-gnulib to add only the files lib/nanosleep.c
and m4/nanosleep.m4 (not the other, signal-related files you mentioned;
they shouldn't be needed with Emacs).
You might also want to adopt my recent little merge-gnulib changes.
I notice that Emacs's GNUstep code calls 'select'. For completeness this
should be 'pselect' instead, so that Emacs never calls 'select'.
[0001-nanosleep-simplify-by-using-pselect.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Sat, 26 Feb 2022 15:13:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> Gnulib's nanosleep appears to use select only for old Unixish
> platforms that were relevant in 2000 but aren't practical porting
> targets any more. So I installed into Gnulib the attached patch to
> simplify Gnulib nanosleep by having it fall back on pselect rather
> than select, and to not bother with signal handling. This should cause
> your addition of nanosleep to admin/merge-gnulib to add only the files
> lib/nanosleep.c and m4/nanosleep.m4 (not the other, signal-related
> files you mentioned; they shouldn't be needed with Emacs).
Thanks; that does indeed fix the issues, and ./admin/merge-gnulib now
works fine for me when I add nanosleep to the list of modules.
> I notice that Emacs's GNUstep code calls 'select'. For completeness
> this should be 'pselect' instead, so that Emacs never calls 'select'.
OK; I'll have a look at that...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 26 Feb 2022 15:13:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Sat, 26 Feb 2022 15:38:01 GMT)
Full text and
rfc822 format available.
Message #85 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Noam Postavsky <npostavs <at> gmail.com>, 32452 <at> debbugs.gnu.org, Eli
> Zaretskii <eliz <at> gnu.org>, Gnulib bugs <bug-gnulib <at> gnu.org>
> Date: Sat, 26 Feb 2022 16:12:23 +0100
>
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
> > Gnulib's nanosleep appears to use select only for old Unixish
> > platforms that were relevant in 2000 but aren't practical porting
> > targets any more. So I installed into Gnulib the attached patch to
> > simplify Gnulib nanosleep by having it fall back on pselect rather
> > than select, and to not bother with signal handling. This should cause
> > your addition of nanosleep to admin/merge-gnulib to add only the files
> > lib/nanosleep.c and m4/nanosleep.m4 (not the other, signal-related
> > files you mentioned; they shouldn't be needed with Emacs).
>
> Thanks; that does indeed fix the issues, and ./admin/merge-gnulib now
> works fine for me when I add nanosleep to the list of modules.
>
> > I notice that Emacs's GNUstep code calls 'select'. For completeness
> > this should be 'pselect' instead, so that Emacs never calls 'select'.
>
> OK; I'll have a look at that...
Please post the patch before landing it. Gnulib's nanosleep is
problematic on MS-Windows (and shouldn't be used there anyway), so I'd
like to eyeball the changes before they are installed.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Sat, 26 Feb 2022 16:06:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Please post the patch before landing it. Gnulib's nanosleep is
> problematic on MS-Windows (and shouldn't be used there anyway), so I'd
> like to eyeball the changes before they are installed.
Will do.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Mon, 28 Feb 2022 09:00:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 32452 <at> debbugs.gnu.org (full text, mbox):
I tried adding nanosleep to the modules, and updated, and then tried to
use nanosleep from gnutls.c. But it doesn't build (on Debian/bookworm):
/usr/bin/ld: gnutls.o: in function `gnutls_try_handshake':
/home/larsi/src/emacs/trunk/src/gnutls.c:634: undefined reference to `rpl_nanosleep'
collect2: error: ld returned 1 exit status
I tried poking at lib/time.h, but I just don't understand how this all
hooks up:
# if 1
# if 1
# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
# define nanosleep rpl_nanosleep
with nanosleep.c...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Mon, 28 Feb 2022 12:30:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eggert <at> cs.ucla.edu, bug-gnulib <at> gnu.org, npostavs <at> gmail.com,
> 32452 <at> debbugs.gnu.org
> Date: Mon, 28 Feb 2022 09:59:39 +0100
>
> /usr/bin/ld: gnutls.o: in function `gnutls_try_handshake':
> /home/larsi/src/emacs/trunk/src/gnutls.c:634: undefined reference to `rpl_nanosleep'
> collect2: error: ld returned 1 exit status
>
> I tried poking at lib/time.h, but I just don't understand how this all
> hooks up:
>
> # if 1
> # if 1
> # if !(defined __cplusplus && defined GNULIB_NAMESPACE)
> # define nanosleep rpl_nanosleep
>
> with nanosleep.c...
And there's no rpl_nanosleep anywhere in sight?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Mon, 28 Feb 2022 12:32:01 GMT)
Full text and
rfc822 format available.
Message #97 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> And there's no rpl_nanosleep anywhere in sight?
Nope:
grep --color=auto -nH --null -e rpl_nanosleep `find . -type f`
./lib/time.h647:# define nanosleep rpl_nanosleep
./lib/time.in.h140:# define nanosleep rpl_nanosleep
And that's it.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Mon, 28 Feb 2022 12:36:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> grep --color=auto -nH --null -e rpl_nanosleep `find . -type f`
> ./lib/time.h647:# define nanosleep rpl_nanosleep
> ./lib/time.in.h140:# define nanosleep rpl_nanosleep
>
> And that's it.
The header file continues:
# if 0
# if GNULIB_PORTCHECK
# if !(defined __cplusplus && defined GNULIB_NAMESPACE)
# define nanosleep rpl_nanosleep
# endif
_GL_FUNCDECL_RPL (nanosleep, int,
(struct timespec const *__rqtp, struct timespec *__rmtp)
_GL_ARG_NONNULL ((1)));
_GL_CXXALIAS_RPL (nanosleep, int,
(struct timespec const *__rqtp, struct timespec *__rmtp));
# else
# if ! 1
_GL_FUNCDECL_SYS (nanosleep, int,
(struct timespec const *__rqtp, struct timespec *__rmtp)
_GL_ARG_NONNULL ((1)));
# endif
_GL_CXXALIAS_SYS (nanosleep, int,
(struct timespec const *__rqtp, struct timespec *__rmtp));
# endif
_GL_CXXALIASWARN (nanosleep);
# endif
So perhaps it's taking the wrong route here somewhere in the
preprocessor, but I don't know how this is supposed to work.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Mon, 28 Feb 2022 12:48:01 GMT)
Full text and
rfc822 format available.
Message #103 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eggert <at> cs.ucla.edu, bug-gnulib <at> gnu.org, npostavs <at> gmail.com,
> 32452 <at> debbugs.gnu.org
> Date: Mon, 28 Feb 2022 13:35:47 +0100
>
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > grep --color=auto -nH --null -e rpl_nanosleep `find . -type f`
> > ./lib/time.h647:# define nanosleep rpl_nanosleep
> > ./lib/time.in.h140:# define nanosleep rpl_nanosleep
> >
> > And that's it.
>
> The header file continues:
>
> # if 0
> # if GNULIB_PORTCHECK
> # if !(defined __cplusplus && defined GNULIB_NAMESPACE)
> # define nanosleep rpl_nanosleep
> # endif
> _GL_FUNCDECL_RPL (nanosleep, int,
> (struct timespec const *__rqtp, struct timespec *__rmtp)
> _GL_ARG_NONNULL ((1)));
> _GL_CXXALIAS_RPL (nanosleep, int,
> (struct timespec const *__rqtp, struct timespec *__rmtp));
My guess is that _GL_FUNCDECL_RPL should produce a rpl_nanosleep.
But I'm sure Gnulib folks will see the reason much faster than my
guesses.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Mon, 28 Feb 2022 21:48:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 32452 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2/28/22 00:59, Lars Ingebrigtsen wrote:
> /usr/bin/ld: gnutls.o: in function `gnutls_try_handshake':
> /home/larsi/src/emacs/trunk/src/gnutls.c:634: undefined reference to `rpl_nanosleep'
Evidently my recent workarounds in Emacs to handle running gnulib-tool
from a bare checkout were not sufficient. I installed the attached patch
to up the ante; please give it a try.
It is unfortunate that emacs/admin/merge-gnulib now runs gnulib-tool
twice from a bare checkout, as gnulib-tool is quite slow.
I think gnulib-tool needs to run twice because it builds
emacs/lib/gnulib.mk.in before it builds emacs/m4/gnulib-comp.m4, and so
doesn't use the newly-added emacs/m4/nanosleep.m4 to figure out the new
X=@X@ lines that needed to be added to emacs/lib/gnulib.mk.in. I suspect
that this is related to Emacs's using Gnu Make rather than Automake.
However, I haven't debugged this out.
[0001-Work-around-merge-gnulib-glitch-from-fresh-checkout.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Tue, 01 Mar 2022 15:37:01 GMT)
Full text and
rfc822 format available.
Message #109 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> Evidently my recent workarounds in Emacs to handle running gnulib-tool
> from a bare checkout were not sufficient. I installed the attached
> patch to up the ante; please give it a try.
>
> It is unfortunate that emacs/admin/merge-gnulib now runs gnulib-tool
> twice from a bare checkout, as gnulib-tool is quite slow.
My latest attempt wasn't from a bare checkout -- it was from my normal
development tree, though.
In any case, doing this:
diff --git a/admin/merge-gnulib b/admin/merge-gnulib
index 7219fadd47..074101f095 100755
--- a/admin/merge-gnulib
+++ b/admin/merge-gnulib
@@ -40,7 +40,7 @@ GNULIB_MODULES=
getloadavg getopt-gnu getrandom gettime gettimeofday gitlog-to-changelog
ieee754-h ignore-value intprops largefile libgmp lstat
manywarnings memmem-simple mempcpy memrchr minmax mkostemp mktime
- nproc nstrftime
+ nanosleep nproc nstrftime
pathmax pipe2 pselect pthread_sigmask
qcopy-acl readlink readlinkat regex
sig2str sigdescr_np socklen stat-time std-gnu11 stdalign stddef stdio
Then running admin/merge-gnulib, and then adding this:
diff --git a/src/gnutls.c b/src/gnutls.c
index 3ec3837067..5389b15b1e 100644
--- a/src/gnutls.c
+++ b/src/gnutls.c
@@ -616,6 +616,7 @@ gnutls_try_handshake (struct Lisp_Process *proc)
gnutls_session_t state = proc->gnutls_state;
int ret;
bool non_blocking = proc->is_non_blocking_client;
+ struct timespec delay = { 0, 1000 * 1000 * 10 };
if (proc->gnutls_complete_negotiation_p)
non_blocking = false;
@@ -630,6 +631,7 @@ gnutls_try_handshake (struct Lisp_Process *proc)
maybe_quit ();
if (non_blocking && ret != GNUTLS_E_INTERRUPTED)
break;
+ nanosleep (&delay, NULL);
}
proc->gnutls_initstage = GNUTLS_STAGE_HANDSHAKE_TRIED;
Still leads to:
/usr/bin/ld: gnutls.o: in function `gnutls_try_handshake':
/home/larsi/src/emacs/gtest/src/gnutls.c:634: undefined reference to `rpl_nanosleep'
collect2: error: ld returned 1 exit status
Are there any further incantations needed to use stuff from gnulib? I
tried to compare with other usages of gnulib stuff, and nothing really
stood out immediately.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Tue, 01 Mar 2022 18:28:02 GMT)
Full text and
rfc822 format available.
Message #112 received at 32452 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 3/1/22 07:36, Lars Ingebrigtsen wrote:
> My latest attempt wasn't from a bare checkout -- it was from my normal
> development tree, though.
Well, that's annoying. :-)
I looked into the problem some more and found what I think is the
underlying problem: gnulib-tool generated lib/gnulib.mk.in before it
generates m4/gnulib-comp.m4, which Makefile-generation relies upon. I
reverted my recent hack to emacs/admin/merge-gnulib and installed the
attached Gnulib patch. Please update to the latest Emacs and Gnulib and
try again.
[0001-Create-lib-Makefile.am-after-gnulib-comp.m4.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Tue, 01 Mar 2022 18:53:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> I looked into the problem some more and found what I think is the
> underlying problem: gnulib-tool generated lib/gnulib.mk.in before it
> generates m4/gnulib-comp.m4, which Makefile-generation relies upon. I
> reverted my recent hack to emacs/admin/merge-gnulib and installed the
> attached Gnulib patch. Please update to the latest Emacs and Gnulib
> and try again.
I tried this now, but the symptoms seem to be the same -- after trying
to use nanosleep, as described before, I still get:
/usr/bin/ld: gnutls.o: in function `gnutls_try_handshake':
/home/larsi/src/emacs/gtest/src/gnutls.c:634: undefined reference to `rpl_nanosleep'
collect2: error: ld returned 1 exit status
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Wed, 02 Mar 2022 01:01:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 32452 <at> debbugs.gnu.org (full text, mbox):
On 3/1/22 10:52, Lars Ingebrigtsen wrote:
> Paul Eggert<eggert <at> cs.ucla.edu> writes:
>
>> I looked into the problem some more and found what I think is the
>> underlying problem: gnulib-tool generated lib/gnulib.mk.in before it
>> generates m4/gnulib-comp.m4, which Makefile-generation relies upon. I
>> reverted my recent hack to emacs/admin/merge-gnulib and installed the
>> attached Gnulib patch. Please update to the latest Emacs and Gnulib
>> and try again.
> I tried this now, but the symptoms seem to be the same -- after trying
> to use nanosleep, as described before, I still get:
>
> /usr/bin/ld: gnutls.o: in function `gnutls_try_handshake':
> /home/larsi/src/emacs/gtest/src/gnutls.c:634: undefined reference to `rpl_nanosleep'
> collect2: error: ld returned 1 exit status
Do you see this problem with a fresh checkout from the latest master
branch, combined with the latest Gnulib? If not, problem solved. If so,
what's the output of 'git status' and of 'git diff' when things fail?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Wed, 02 Mar 2022 01:23:02 GMT)
Full text and
rfc822 format available.
Message #121 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> Do you see this problem with a fresh checkout from the latest master
> branch, combined with the latest Gnulib?
Yes, when I add the nanosleep module as previously described.
> If not, problem solved. If so, what's the output of 'git status' and
> of 'git diff' when things fail?
larsi <at> giant:~/src/emacs/gtest$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: lib/nanosleep.c
new file: m4/nanosleep.m4
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: admin/merge-gnulib
modified: lib/gnulib.mk.in
modified: m4/gnulib-comp.m4
modified: src/gnutls.c
diff --git a/admin/merge-gnulib b/admin/merge-gnulib
index fec469c017..ea3d23686f 100755
--- a/admin/merge-gnulib
+++ b/admin/merge-gnulib
@@ -40,7 +40,7 @@ GNULIB_MODULES=
getloadavg getopt-gnu getrandom gettime gettimeofday gitlog-to-changelog
ieee754-h ignore-value intprops largefile libgmp lstat
manywarnings memmem-simple mempcpy memrchr minmax mkostemp mktime
- nproc nstrftime
+ nanosleep nproc nstrftime
pathmax pipe2 pselect pthread_sigmask
qcopy-acl readlink readlinkat regex
sig2str sigdescr_np socklen stat-time std-gnu11 stdalign stddef stdio
diff --git a/lib/gnulib.mk.in b/lib/gnulib.mk.in
index 3a9f5b9818..b79eebc804 100644
--- a/lib/gnulib.mk.in
+++ b/lib/gnulib.mk.in
@@ -129,6 +129,7 @@
# minmax \
# mkostemp \
# mktime \
+# nanosleep \
# nproc \
# nstrftime \
# pathmax \
@@ -2497,6 +2498,16 @@ EXTRA_libgnu_a_SOURCES += mktime.c
endif
## end gnulib module mktime-internal
+## begin gnulib module nanosleep
+ifeq (,$(OMIT_GNULIB_MODULE_nanosleep))
+
+ifneq (,$(GL_COND_OBJ_NANOSLEEP_CONDITION))
+libgnu_a_SOURCES += nanosleep.c
+endif
+
+endif
+## end gnulib module nanosleep
+
## begin gnulib module nproc
ifeq (,$(OMIT_GNULIB_MODULE_nproc))
diff --git a/m4/gnulib-comp.m4 b/m4/gnulib-comp.m4
index 1d31239d2d..fb5f1b52a4 100644
--- a/m4/gnulib-comp.m4
+++ b/m4/gnulib-comp.m4
@@ -140,6 +140,7 @@ AC_DEFUN
# Code from module mktime:
# Code from module mktime-internal:
# Code from module multiarch:
+ # Code from module nanosleep:
# Code from module nocrash:
# Code from module nproc:
# Code from module nstrftime:
@@ -430,6 +431,10 @@ AC_DEFUN
fi
gl_TIME_MODULE_INDICATOR([mktime])
gl_MULTIARCH
+ gl_FUNC_NANOSLEEP
+ gl_CONDITIONAL([GL_COND_OBJ_NANOSLEEP],
+ [test $HAVE_NANOSLEEP = 0 || test $REPLACE_NANOSLEEP = 1])
+ gl_TIME_MODULE_INDICATOR([nanosleep])
gl_NPROC
gl_FUNC_GNU_STRFTIME
gl_PATHMAX
@@ -1304,6 +1309,7 @@ AC_DEFUN
lib/mkostemp.c
lib/mktime-internal.h
lib/mktime.c
+ lib/nanosleep.c
lib/nproc.c
lib/nproc.h
lib/nstrftime.c
@@ -1456,6 +1462,7 @@ AC_DEFUN
m4/mktime.m4
m4/mode_t.m4
m4/multiarch.m4
+ m4/nanosleep.m4
m4/nocrash.m4
m4/nproc.m4
m4/nstrftime.m4
diff --git a/src/gnutls.c b/src/gnutls.c
index 3ec3837067..5389b15b1e 100644
--- a/src/gnutls.c
+++ b/src/gnutls.c
@@ -616,6 +616,7 @@ gnutls_try_handshake (struct Lisp_Process *proc)
gnutls_session_t state = proc->gnutls_state;
int ret;
bool non_blocking = proc->is_non_blocking_client;
+ struct timespec delay = { 0, 1000 * 1000 * 10 };
if (proc->gnutls_complete_negotiation_p)
non_blocking = false;
@@ -630,6 +631,7 @@ gnutls_try_handshake (struct Lisp_Process *proc)
maybe_quit ();
if (non_blocking && ret != GNUTLS_E_INTERRUPTED)
break;
+ nanosleep (&delay, NULL);
}
proc->gnutls_initstage = GNUTLS_STAGE_HANDSHAKE_TRIED;
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Wed, 02 Mar 2022 01:44:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> diff --git a/admin/merge-gnulib b/admin/merge-gnulib
> index fec469c017..ea3d23686f 100755
That wasn't the complete diff. Here it is:
diff --git a/admin/merge-gnulib b/admin/merge-gnulib
index fec469c017..ea3d23686f 100755
--- a/admin/merge-gnulib
+++ b/admin/merge-gnulib
@@ -40,7 +40,7 @@ GNULIB_MODULES=
getloadavg getopt-gnu getrandom gettime gettimeofday gitlog-to-changelog
ieee754-h ignore-value intprops largefile libgmp lstat
manywarnings memmem-simple mempcpy memrchr minmax mkostemp mktime
- nproc nstrftime
+ nanosleep nproc nstrftime
pathmax pipe2 pselect pthread_sigmask
qcopy-acl readlink readlinkat regex
sig2str sigdescr_np socklen stat-time std-gnu11 stdalign stddef stdio
diff --git a/lib/gnulib.mk.in b/lib/gnulib.mk.in
index 3a9f5b9818..b79eebc804 100644
--- a/lib/gnulib.mk.in
+++ b/lib/gnulib.mk.in
@@ -129,6 +129,7 @@
# minmax \
# mkostemp \
# mktime \
+# nanosleep \
# nproc \
# nstrftime \
# pathmax \
@@ -2497,6 +2498,16 @@ EXTRA_libgnu_a_SOURCES += mktime.c
endif
## end gnulib module mktime-internal
+## begin gnulib module nanosleep
+ifeq (,$(OMIT_GNULIB_MODULE_nanosleep))
+
+ifneq (,$(GL_COND_OBJ_NANOSLEEP_CONDITION))
+libgnu_a_SOURCES += nanosleep.c
+endif
+
+endif
+## end gnulib module nanosleep
+
## begin gnulib module nproc
ifeq (,$(OMIT_GNULIB_MODULE_nproc))
diff --git a/lib/nanosleep.c b/lib/nanosleep.c
new file mode 100644
index 0000000000..446794edc0
--- /dev/null
+++ b/lib/nanosleep.c
@@ -0,0 +1,195 @@
+/* Provide a replacement for the POSIX nanosleep function.
+
+ Copyright (C) 1999-2000, 2002, 2004-2022 Free Software Foundation, Inc.
+
+ This file is free software: you can redistribute it and/or modify
+ it under the terms of the GNU Lesser General Public License as
+ published by the Free Software Foundation; either version 2.1 of the
+ License, or (at your option) any later version.
+
+ This file is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with this program. If not, see <https://www.gnu.org/licenses/>. */
+
+/* written by Jim Meyering
+ and Bruno Haible for the native Windows part */
+
+#include <config.h>
+
+#include <time.h>
+
+#include "intprops.h"
+#include "verify.h"
+
+#include <stdbool.h>
+#include <stdio.h>
+#include <sys/types.h>
+#include <sys/select.h>
+#include <signal.h>
+
+#include <errno.h>
+
+#include <unistd.h>
+
+
+enum { BILLION = 1000 * 1000 * 1000 };
+
+#if HAVE_BUG_BIG_NANOSLEEP
+
+int
+nanosleep (const struct timespec *requested_delay,
+ struct timespec *remaining_delay)
+# undef nanosleep
+{
+ /* nanosleep mishandles large sleeps due to internal overflow problems.
+ The worst known case of this is Linux 2.6.9 with glibc 2.3.4, which
+ can't sleep more than 24.85 days (2^31 milliseconds). Similarly,
+ cygwin 1.5.x, which can't sleep more than 49.7 days (2^32 milliseconds).
+ Solve this by breaking the sleep up into smaller chunks. */
+
+ if (requested_delay->tv_nsec < 0 || BILLION <= requested_delay->tv_nsec)
+ {
+ errno = EINVAL;
+ return -1;
+ }
+
+ {
+ /* Verify that time_t is large enough. */
+ verify (TYPE_MAXIMUM (time_t) / 24 / 24 / 60 / 60);
+ const time_t limit = 24 * 24 * 60 * 60;
+ time_t seconds = requested_delay->tv_sec;
+ struct timespec intermediate;
+ intermediate.tv_nsec = requested_delay->tv_nsec;
+
+ while (limit < seconds)
+ {
+ int result;
+ intermediate.tv_sec = limit;
+ result = nanosleep (&intermediate, remaining_delay);
+ seconds -= limit;
+ if (result)
+ {
+ if (remaining_delay)
+ remaining_delay->tv_sec += seconds;
+ return result;
+ }
+ intermediate.tv_nsec = 0;
+ }
+ intermediate.tv_sec = seconds;
+ return nanosleep (&intermediate, remaining_delay);
+ }
+}
+
+#elif defined _WIN32 && ! defined __CYGWIN__
+/* Native Windows platforms. */
+
+# define WIN32_LEAN_AND_MEAN
+# include <windows.h>
+
+/* The Windows API function Sleep() has a resolution of about 15 ms and takes
+ at least 5 ms to execute. We use this function for longer time periods.
+ Additionally, we use busy-looping over short time periods, to get a
+ resolution of about 0.01 ms. In order to measure such short timespans,
+ we use the QueryPerformanceCounter() function. */
+
+int
+nanosleep (const struct timespec *requested_delay,
+ struct timespec *remaining_delay)
+{
+ static bool initialized;
+ /* Number of performance counter increments per nanosecond,
+ or zero if it could not be determined. */
+ static double ticks_per_nanosecond;
+
+ if (requested_delay->tv_nsec < 0 || BILLION <= requested_delay->tv_nsec)
+ {
+ errno = EINVAL;
+ return -1;
+ }
+
+ /* For requested delays of one second or more, 15ms resolution is
+ sufficient. */
+ if (requested_delay->tv_sec == 0)
+ {
+ if (!initialized)
+ {
+ /* Initialize ticks_per_nanosecond. */
+ LARGE_INTEGER ticks_per_second;
+
+ if (QueryPerformanceFrequency (&ticks_per_second))
+ ticks_per_nanosecond =
+ (double) ticks_per_second.QuadPart / 1000000000.0;
+
+ initialized = true;
+ }
+ if (ticks_per_nanosecond)
+ {
+ /* QueryPerformanceFrequency worked. We can use
+ QueryPerformanceCounter. Use a combination of Sleep and
+ busy-looping. */
+ /* Number of milliseconds to pass to the Sleep function.
+ Since Sleep can take up to 8 ms less or 8 ms more than requested
+ (or maybe more if the system is loaded), we subtract 10 ms. */
+ int sleep_millis = (int) requested_delay->tv_nsec / 1000000 - 10;
+ /* Determine how many ticks to delay. */
+ LONGLONG wait_ticks = requested_delay->tv_nsec * ticks_per_nanosecond;
+ /* Start. */
+ LARGE_INTEGER counter_before;
+ if (QueryPerformanceCounter (&counter_before))
+ {
+ /* Wait until the performance counter has reached this value.
+ We don't need to worry about overflow, because the performance
+ counter is reset at reboot, and with a frequency of 3.6E6
+ ticks per second 63 bits suffice for over 80000 years. */
+ LONGLONG wait_until = counter_before.QuadPart + wait_ticks;
+ /* Use Sleep for the longest part. */
+ if (sleep_millis > 0)
+ Sleep (sleep_millis);
+ /* Busy-loop for the rest. */
+ for (;;)
+ {
+ LARGE_INTEGER counter_after;
+ if (!QueryPerformanceCounter (&counter_after))
+ /* QueryPerformanceCounter failed, but succeeded earlier.
+ Should not happen. */
+ break;
+ if (counter_after.QuadPart >= wait_until)
+ /* The requested time has elapsed. */
+ break;
+ }
+ goto done;
+ }
+ }
+ }
+ /* Implementation for long delays and as fallback. */
+ Sleep (requested_delay->tv_sec * 1000 + requested_delay->tv_nsec / 1000000);
+
+ done:
+ /* Sleep is not interruptible. So there is no remaining delay. */
+ if (remaining_delay != NULL)
+ {
+ remaining_delay->tv_sec = 0;
+ remaining_delay->tv_nsec = 0;
+ }
+ return 0;
+}
+
+#else
+/* Other platforms lacking nanosleep.
+ It's not clear whether these are still practical porting targets.
+ For now, just fall back on pselect. */
+
+/* Suspend execution for at least *REQUESTED_DELAY seconds. The
+ *REMAINING_DELAY part isn't implemented yet. */
+
+int
+nanosleep (const struct timespec *requested_delay,
+ struct timespec *remaining_delay)
+{
+ return pselect (0, NULL, NULL, NULL, requested_delay, NULL);
+}
+#endif
diff --git a/m4/gnulib-comp.m4 b/m4/gnulib-comp.m4
index 1d31239d2d..fb5f1b52a4 100644
--- a/m4/gnulib-comp.m4
+++ b/m4/gnulib-comp.m4
@@ -140,6 +140,7 @@ AC_DEFUN
# Code from module mktime:
# Code from module mktime-internal:
# Code from module multiarch:
+ # Code from module nanosleep:
# Code from module nocrash:
# Code from module nproc:
# Code from module nstrftime:
@@ -430,6 +431,10 @@ AC_DEFUN
fi
gl_TIME_MODULE_INDICATOR([mktime])
gl_MULTIARCH
+ gl_FUNC_NANOSLEEP
+ gl_CONDITIONAL([GL_COND_OBJ_NANOSLEEP],
+ [test $HAVE_NANOSLEEP = 0 || test $REPLACE_NANOSLEEP = 1])
+ gl_TIME_MODULE_INDICATOR([nanosleep])
gl_NPROC
gl_FUNC_GNU_STRFTIME
gl_PATHMAX
@@ -1304,6 +1309,7 @@ AC_DEFUN
lib/mkostemp.c
lib/mktime-internal.h
lib/mktime.c
+ lib/nanosleep.c
lib/nproc.c
lib/nproc.h
lib/nstrftime.c
@@ -1456,6 +1462,7 @@ AC_DEFUN
m4/mktime.m4
m4/mode_t.m4
m4/multiarch.m4
+ m4/nanosleep.m4
m4/nocrash.m4
m4/nproc.m4
m4/nstrftime.m4
diff --git a/m4/nanosleep.m4 b/m4/nanosleep.m4
new file mode 100644
index 0000000000..1964b1ea47
--- /dev/null
+++ b/m4/nanosleep.m4
@@ -0,0 +1,139 @@
+# serial 41
+
+dnl From Jim Meyering.
+dnl Check for the nanosleep function.
+dnl If not found, use the supplied replacement.
+dnl
+
+# Copyright (C) 1999-2001, 2003-2022 Free Software Foundation, Inc.
+
+# This file is free software; the Free Software Foundation
+# gives unlimited permission to copy and/or distribute it,
+# with or without modifications, as long as this notice is preserved.
+
+AC_DEFUN([gl_FUNC_NANOSLEEP],
+[
+ AC_REQUIRE([gl_TIME_H_DEFAULTS])
+ AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
+
+ dnl Persuade glibc and Solaris <time.h> to declare nanosleep.
+ AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
+
+ AC_CHECK_DECLS_ONCE([alarm])
+
+ nanosleep_save_libs=$LIBS
+
+ # Solaris 2.5.1 needs -lposix4 to get the nanosleep function.
+ # Solaris 7 prefers the library name -lrt to the obsolescent name -lposix4.
+ LIB_NANOSLEEP=
+ AC_SUBST([LIB_NANOSLEEP])
+ AC_SEARCH_LIBS([nanosleep], [rt posix4],
+ [test "$ac_cv_search_nanosleep" = "none required" ||
+ LIB_NANOSLEEP=$ac_cv_search_nanosleep])
+ if test "x$ac_cv_search_nanosleep" != xno; then
+ dnl The system has a nanosleep function.
+
+ AC_REQUIRE([gl_MULTIARCH])
+ if test $APPLE_UNIVERSAL_BUILD = 1; then
+ # A universal build on Apple Mac OS X platforms.
+ # The test result would be 'no (mishandles large arguments)' in 64-bit
+ # mode but 'yes' in 32-bit mode. But we need a configuration result that
+ # is valid in both modes.
+ gl_cv_func_nanosleep='no (mishandles large arguments)'
+ fi
+
+ AC_CACHE_CHECK([for working nanosleep],
+ [gl_cv_func_nanosleep],
+ [
+ AC_RUN_IFELSE(
+ [AC_LANG_SOURCE([[
+ #include <errno.h>
+ #include <limits.h>
+ #include <signal.h>
+ #include <time.h>
+ #include <unistd.h>
+ #define TYPE_SIGNED(t) (! ((t) 0 < (t) -1))
+ #define TYPE_MAXIMUM(t) \
+ ((t) (! TYPE_SIGNED (t) \
+ ? (t) -1 \
+ : ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 1)))
+
+ #if HAVE_DECL_ALARM
+ static void
+ check_for_SIGALRM (int sig)
+ {
+ if (sig != SIGALRM)
+ _exit (1);
+ }
+ #endif
+
+ int
+ main ()
+ {
+ static struct timespec ts_sleep;
+ static struct timespec ts_remaining;
+ /* Test for major problems first. */
+ if (! nanosleep)
+ return 2;
+ ts_sleep.tv_sec = 0;
+ ts_sleep.tv_nsec = 1;
+ #if HAVE_DECL_ALARM
+ {
+ static struct sigaction act;
+ act.sa_handler = check_for_SIGALRM;
+ sigemptyset (&act.sa_mask);
+ sigaction (SIGALRM, &act, NULL);
+ alarm (1);
+ if (nanosleep (&ts_sleep, NULL) != 0)
+ return 3;
+ /* Test for a minor problem: the handling of large arguments. */
+ ts_sleep.tv_sec = TYPE_MAXIMUM (time_t);
+ ts_sleep.tv_nsec = 999999999;
+ alarm (1);
+ if (nanosleep (&ts_sleep, &ts_remaining) != -1)
+ return 4;
+ if (errno != EINTR)
+ return 5;
+ if (ts_remaining.tv_sec <= TYPE_MAXIMUM (time_t) - 10)
+ return 6;
+ }
+ #else /* A simpler test for native Windows. */
+ if (nanosleep (&ts_sleep, &ts_remaining) < 0)
+ return 3;
+ #endif
+ return 0;
+ }]])],
+ [gl_cv_func_nanosleep=yes],
+ [case $? in dnl (
+ 4|5|6) gl_cv_func_nanosleep='no (mishandles large arguments)';; dnl (
+ *) gl_cv_func_nanosleep=no;;
+ esac],
+ [case "$host_os" in dnl ((
+ linux*) # Guess it halfway works when the kernel is Linux.
+ gl_cv_func_nanosleep='guessing no (mishandles large arguments)' ;;
+ mingw*) # Guess no on native Windows.
+ gl_cv_func_nanosleep='guessing no' ;;
+ *) # If we don't know, obey --enable-cross-guesses.
+ gl_cv_func_nanosleep="$gl_cross_guess_normal" ;;
+ esac
+ ])
+ ])
+ case "$gl_cv_func_nanosleep" in
+ *yes)
+ REPLACE_NANOSLEEP=0
+ ;;
+ *)
+ REPLACE_NANOSLEEP=1
+ case "$gl_cv_func_nanosleep" in
+ *"mishandles large arguments"*)
+ AC_DEFINE([HAVE_BUG_BIG_NANOSLEEP], [1],
+ [Define to 1 if nanosleep mishandles large arguments.])
+ ;;
+ esac
+ ;;
+ esac
+ else
+ HAVE_NANOSLEEP=0
+ fi
+ LIBS=$nanosleep_save_libs
+])
diff --git a/src/gnutls.c b/src/gnutls.c
index 3ec3837067..5389b15b1e 100644
--- a/src/gnutls.c
+++ b/src/gnutls.c
@@ -616,6 +616,7 @@ gnutls_try_handshake (struct Lisp_Process *proc)
gnutls_session_t state = proc->gnutls_state;
int ret;
bool non_blocking = proc->is_non_blocking_client;
+ struct timespec delay = { 0, 1000 * 1000 * 10 };
if (proc->gnutls_complete_negotiation_p)
non_blocking = false;
@@ -630,6 +631,7 @@ gnutls_try_handshake (struct Lisp_Process *proc)
maybe_quit ();
if (non_blocking && ret != GNUTLS_E_INTERRUPTED)
break;
+ nanosleep (&delay, NULL);
}
proc->gnutls_initstage = GNUTLS_STAGE_HANDSHAKE_TRIED;
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Wed, 02 Mar 2022 02:13:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 32452 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 3/1/22 17:22, Lars Ingebrigtsen wrote:
> --- a/lib/gnulib.mk.in
> +++ b/lib/gnulib.mk.in
> @@ -129,6 +129,7 @@
> # minmax \
> # mkostemp \
> # mktime \
> +# nanosleep \
> # nproc \
> # nstrftime \
> # pathmax \
> @@ -2497,6 +2498,16 @@ EXTRA_libgnu_a_SOURCES += mktime.c
> endif
> ## end gnulib module mktime-internal
>
> +## begin gnulib module nanosleep
> +ifeq (,$(OMIT_GNULIB_MODULE_nanosleep))
> +
> +ifneq (,$(GL_COND_OBJ_NANOSLEEP_CONDITION))
> +libgnu_a_SOURCES += nanosleep.c
> +endif
> +
> +endif
> +## end gnulib module nanosleep
> +
> ## begin gnulib module nproc
> ifeq (,$(OMIT_GNULIB_MODULE_nproc))
>
This diff is wrong, as it omits a line "GL_COND_OBJ_NANOSLEEP_CONDITION
= @GL_COND_OBJ_NANOSLEEP_CONDITION@".
I ran what should have been something like your commands and got the
attached patch. One way forward is for you to simply install the
attached patch and move on from there. Or we can continue to look into
why things work for me and not for you. I suppose it could be an
Autoconf bug on your platform, but it'd be an odd one.
Here's a shell transcript of what I did to get the attached patch, on
Fedora 35 x86-64:
$ git clone master master-tmp
Cloning into 'master-tmp'...
done.
Updating files: 100% (4608/4608), done.
$ cd master-tmp
$ git log HEAD^!
commit 689a34e2153ec558dbf406809a5e58489250fe1a (HEAD -> master,
origin/master, origin/HEAD)
Author: Po Lu <luangruo <at> yahoo.com>
Date: Wed Mar 2 09:46:44 2022 +0800
Dismiss help text when item becomes unactivated on oldXMenu
* oldXMenu/Activate.c (XMenuActivate): Dismiss help text when
leaving an item.
$ (cd ../gnulib && git log HEAD^! )
commit 8c4f4d7a3c28f88b64fce2fb1d0dc0e570d1a482 (HEAD -> master,
origin/master, origin/HEAD)
Author: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Tue Mar 1 10:01:22 2022 -0800
Create lib/Makefile.am after gnulib-comp.m4
* gnulib-tool (func_import): Create library makefile after
creating gnulib-comp.m4. With --gnu-make, the latter depends on
the former. See <https://bugs.gnu.org/32452#109>.
$ sed -i 's/nproc nstrftime/nanosleep &/' admin/merge-gnulib
$ admin/merge-gnulib
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65) ... ok
Your system has the required tools.
Building aclocal.m4 ...
Running 'autoreconf -fi -I m4' ...
Configuring local git repository...
'.git/config' -> '.git/config.~1~'
git config transfer.fsckObjects 'true'
git config diff.cpp.xfuncname '!^[
\t]*[A-Za-z_][A-Za-z_0-9]*:[[:space:]]*($|/[/*])
^((::[[:space:]]*)?[A-Za-z_][A-Za-z_0-9]*[[:space:]]*\(.*)$
^((#define[[:space:]]|DEFUN).*)$'
git config diff.elisp.xfuncname
'^\([^[:space:]]*def[^[:space:]]+[[:space:]]+([^()[:space:]]+)'
git config diff.m4.xfuncname '^((m4_)?define|A._DEFUN(_ONCE)?)\([^),]*'
git config diff.make.xfuncname
'^([$.[:alnum:]_].*:|[[:alnum:]_]+[[:space:]]*([*:+]?[:?]?|!?)=|define .*)'
git config diff.shell.xfuncname
'^([[:space:]]*[[:alpha:]_][[:alnum:]_]*[[:space:]]*\(\)|[[:alpha:]_][[:alnum:]_]*=)'
git config diff.texinfo.xfuncname
'^@node[[:space:]]+([^,[:space:]][^,]+)'
Installing git hooks...
'build-aux/git-hooks/commit-msg' -> '.git/hooks/commit-msg'
'build-aux/git-hooks/pre-commit' -> '.git/hooks/pre-commit'
'build-aux/git-hooks/prepare-commit-msg' ->
'.git/hooks/prepare-commit-msg'
'.git/hooks/applypatch-msg.sample' -> '.git/hooks/applypatch-msg'
'.git/hooks/pre-applypatch.sample' -> '.git/hooks/pre-applypatch'
You can now run './configure'.
Module list with included dependencies (indented):
absolute-header
acl-permissions
alloca-opt
allocator
at-internal
attribute
binary-io
builtin-expect
byteswap
c-ctype
c-strcase
c99
canonicalize-lgpl
careadlinkat
clock-time
cloexec
close-stream
copy-file-range
count-leading-zeros
count-one-bits
count-trailing-zeros
crypto/md5
crypto/md5-buffer
crypto/sha1-buffer
crypto/sha256-buffer
crypto/sha512-buffer
d-type
diffseq
dirent
dirfd
double-slash-root
dtoastr
dtotimespec
dup2
dynarray
eloop-threshold
environ
errno
euidaccess
execinfo
explicit_bzero
extensions
extern-inline
faccessat
fchmodat
fcntl
fcntl-h
fdopendir
file-has-acl
filemode
filename
filevercmp
flexmember
fpending
fpieee
free-posix
fstatat
fsusage
fsync
futimens
gen-header
getdtablesize
getgroups
getloadavg
getopt-gnu
getopt-posix
getrandom
gettext-h
gettime
gettimeofday
gitlog-to-changelog
group-member
idx
ieee754-h
ignore-value
include_next
intprops
inttypes-incomplete
largefile
lchmod
libc-config
libgmp
limits-h
lstat
malloc-gnu
malloc-posix
manywarnings
memmem-simple
mempcpy
memrchr
minmax
mkostemp
mktime
mktime-internal
multiarch
nanosleep
nocrash
nproc
nstrftime
open
openat-h
pathmax
pipe2
pselect
pthread_sigmask
qcopy-acl
rawmemchr
readlink
readlinkat
realloc-gnu
realloc-posix
regex
root-uid
scratch_buffer
sig2str
sigdescr_np
signal-h
snippet/_Noreturn
snippet/arg-nonnull
snippet/c++defs
snippet/warn-on-use
socklen
ssize_t
stat-time
std-gnu11
stdalign
stddef
stdint
stdio
stdlib
stpcpy
string
strnlen
strtoimax
strtoll
symlink
sys_random
sys_select
sys_stat
sys_time
sys_types
tempname
time
time_r
time_rz
timegm
timer-time
timespec
timespec-add
timespec-sub
u64
unistd
unlocked-io
unlocked-io-internal
update-copyright
utimens
utimensat
vararrays
verify
vla
warnings
xalloc-oversized
File list:
build-aux/gitlog-to-changelog
build-aux/update-copyright
lib/_Noreturn.h
lib/acl-errno-valid.c
lib/acl-internal.c
lib/acl-internal.h
lib/acl.h
lib/acl_entries.c
lib/alloca.in.h
lib/allocator.c
lib/allocator.h
lib/arg-nonnull.h
lib/at-func.c
lib/attribute.h
lib/binary-io.c
lib/binary-io.h
lib/byteswap.in.h
lib/c++defs.h
lib/c-ctype.c
lib/c-ctype.h
lib/c-strcase.h
lib/c-strcasecmp.c
lib/c-strncasecmp.c
lib/canonicalize-lgpl.c
lib/careadlinkat.c
lib/careadlinkat.h
lib/cdefs.h
lib/cloexec.c
lib/cloexec.h
lib/close-stream.c
lib/close-stream.h
lib/copy-file-range.c
lib/count-leading-zeros.c
lib/count-leading-zeros.h
lib/count-one-bits.c
lib/count-one-bits.h
lib/count-trailing-zeros.c
lib/count-trailing-zeros.h
lib/diffseq.h
lib/dirent.in.h
lib/dirfd.c
lib/dtoastr.c
lib/dtotimespec.c
lib/dup2.c
lib/dynarray.h
lib/eloop-threshold.h
lib/errno.in.h
lib/euidaccess.c
lib/execinfo.c
lib/execinfo.in.h
lib/explicit_bzero.c
lib/faccessat.c
lib/fchmodat.c
lib/fcntl.c
lib/fcntl.in.h
lib/fdopendir.c
lib/file-has-acl.c
lib/filemode.c
lib/filemode.h
lib/filename.h
lib/filevercmp.c
lib/filevercmp.h
lib/flexmember.h
lib/fpending.c
lib/fpending.h
lib/free.c
lib/fstatat.c
lib/fsusage.c
lib/fsusage.h
lib/fsync.c
lib/ftoastr.c
lib/ftoastr.h
lib/futimens.c
lib/get-permissions.c
lib/getdtablesize.c
lib/getgroups.c
lib/getloadavg.c
lib/getopt-cdefs.in.h
lib/getopt-core.h
lib/getopt-ext.h
lib/getopt-pfx-core.h
lib/getopt-pfx-ext.h
lib/getopt.c
lib/getopt.in.h
lib/getopt1.c
lib/getopt_int.h
lib/getrandom.c
lib/gettext.h
lib/gettime.c
lib/gettimeofday.c
lib/gl_openssl.h
lib/group-member.c
lib/idx.h
lib/ieee754.in.h
lib/ignore-value.h
lib/intprops.h
lib/inttypes.in.h
lib/lchmod.c
lib/libc-config.h
lib/limits.in.h
lib/lstat.c
lib/malloc.c
lib/malloc/dynarray-skeleton.c
lib/malloc/dynarray.h
lib/malloc/dynarray_at_failure.c
lib/malloc/dynarray_emplace_enlarge.c
lib/malloc/dynarray_finalize.c
lib/malloc/dynarray_resize.c
lib/malloc/dynarray_resize_clear.c
lib/malloc/scratch_buffer.h
lib/malloc/scratch_buffer_dupfree.c
lib/malloc/scratch_buffer_grow.c
lib/malloc/scratch_buffer_grow_preserve.c
lib/malloc/scratch_buffer_set_array_size.c
lib/md5-stream.c
lib/md5.c
lib/md5.h
lib/memmem.c
lib/mempcpy.c
lib/memrchr.c
lib/mini-gmp-gnulib.c
lib/mini-gmp.c
lib/mini-gmp.h
lib/minmax.h
lib/mkostemp.c
lib/mktime-internal.h
lib/mktime.c
lib/nanosleep.c
lib/nproc.c
lib/nproc.h
lib/nstrftime.c
lib/open.c
lib/openat-priv.h
lib/openat-proc.c
lib/openat.h
lib/pathmax.h
lib/pipe2.c
lib/pselect.c
lib/pthread_sigmask.c
lib/qcopy-acl.c
lib/rawmemchr.c
lib/rawmemchr.valgrind
lib/readlink.c
lib/readlinkat.c
lib/realloc.c
lib/regcomp.c
lib/regex.c
lib/regex.h
lib/regex_internal.c
lib/regex_internal.h
lib/regexec.c
lib/root-uid.h
lib/scratch_buffer.h
lib/set-permissions.c
lib/sha1.c
lib/sha1.h
lib/sha256.c
lib/sha256.h
lib/sha512.c
lib/sha512.h
lib/sig2str.c
lib/sig2str.h
lib/sigdescr_np.c
lib/signal.in.h
lib/stat-time.c
lib/stat-time.h
lib/stdalign.in.h
lib/stddef.in.h
lib/stdint.in.h
lib/stdio-impl.h
lib/stdio-read.c
lib/stdio-write.c
lib/stdio.in.h
lib/stdlib.in.h
lib/stpcpy.c
lib/str-two-way.h
lib/strftime.h
lib/string.in.h
lib/strnlen.c
lib/strtoimax.c
lib/strtol.c
lib/strtoll.c
lib/symlink.c
lib/sys_random.in.h
lib/sys_select.in.h
lib/sys_stat.in.h
lib/sys_time.in.h
lib/sys_types.in.h
lib/tempname.c
lib/tempname.h
lib/time-internal.h
lib/time.in.h
lib/time_r.c
lib/time_rz.c
lib/timegm.c
lib/timespec-add.c
lib/timespec-sub.c
lib/timespec.c
lib/timespec.h
lib/u64.c
lib/u64.h
lib/unistd.c
lib/unistd.in.h
lib/unlocked-io.h
lib/utimens.c
lib/utimens.h
lib/utimensat.c
lib/verify.h
lib/vla.h
lib/warn-on-use.h
lib/xalloc-oversized.h
m4/00gnulib.m4
m4/__inline.m4
m4/absolute-header.m4
m4/acl.m4
m4/alloca.m4
m4/builtin-expect.m4
m4/byteswap.m4
m4/canonicalize.m4
m4/clock_time.m4
m4/copy-file-range.m4
m4/d-type.m4
m4/dirent_h.m4
m4/dirfd.m4
m4/double-slash-root.m4
m4/dup2.m4
m4/eealloc.m4
m4/environ.m4
m4/errno_h.m4
m4/euidaccess.m4
m4/execinfo.m4
m4/explicit_bzero.m4
m4/extensions.m4
m4/extern-inline.m4
m4/faccessat.m4
m4/fchmodat.m4
m4/fcntl-o.m4
m4/fcntl.m4
m4/fcntl_h.m4
m4/fdopendir.m4
m4/filemode.m4
m4/flexmember.m4
m4/fpending.m4
m4/fpieee.m4
m4/free.m4
m4/fstatat.m4
m4/fsusage.m4
m4/fsync.m4
m4/futimens.m4
m4/getdtablesize.m4
m4/getgroups.m4
m4/getloadavg.m4
m4/getopt.m4
m4/getrandom.m4
m4/gettime.m4
m4/gettimeofday.m4
m4/gl-openssl.m4
m4/gnulib-common.m4
m4/group-member.m4
m4/ieee754-h.m4
m4/include_next.m4
m4/inttypes.m4
m4/largefile.m4
m4/lchmod.m4
m4/libgmp.m4
m4/limits-h.m4
m4/lstat.m4
m4/malloc.m4
m4/manywarnings-c++.m4
m4/manywarnings.m4
m4/mbstate_t.m4
m4/md5.m4
m4/memmem.m4
m4/mempcpy.m4
m4/memrchr.m4
m4/minmax.m4
m4/mkostemp.m4
m4/mktime.m4
m4/mode_t.m4
m4/multiarch.m4
m4/nanosleep.m4
m4/nocrash.m4
m4/nproc.m4
m4/nstrftime.m4
m4/off_t.m4
m4/open-cloexec.m4
m4/open-slash.m4
m4/open.m4
m4/pathmax.m4
m4/pid_t.m4
m4/pipe2.m4
m4/pselect.m4
m4/pthread_sigmask.m4
m4/rawmemchr.m4
m4/readlink.m4
m4/readlinkat.m4
m4/realloc.m4
m4/regex.m4
m4/sha1.m4
m4/sha256.m4
m4/sha512.m4
m4/sig2str.m4
m4/sigdescr_np.m4
m4/signal_h.m4
m4/socklen.m4
m4/ssize_t.m4
m4/stat-time.m4
m4/std-gnu11.m4
m4/stdalign.m4
m4/stddef_h.m4
m4/stdint.m4
m4/stdio_h.m4
m4/stdlib_h.m4
m4/stpcpy.m4
m4/string_h.m4
m4/strnlen.m4
m4/strtoimax.m4
m4/strtoll.m4
m4/symlink.m4
m4/sys_random_h.m4
m4/sys_select_h.m4
m4/sys_socket_h.m4
m4/sys_stat_h.m4
m4/sys_time_h.m4
m4/sys_types_h.m4
m4/tempname.m4
m4/time_h.m4
m4/time_r.m4
m4/time_rz.m4
m4/timegm.m4
m4/timer_time.m4
m4/timespec.m4
m4/tm_gmtoff.m4
m4/unistd_h.m4
m4/unlocked-io.m4
m4/utimens.m4
m4/utimensat.m4
m4/utimes.m4
m4/vararrays.m4
m4/warn-on-use.m4
m4/warnings.m4
m4/wchar_t.m4
m4/wint_t.m4
m4/year2038.m4
m4/zzgnulib.m4
Copying file lib/gl_openssl.h
Copying file lib/nanosleep.c
Copying file lib/stdio-read.c
Copying file lib/stdio-write.c
Copying file m4/fcntl-o.m4
Copying file m4/gl-openssl.m4
Copying file m4/gnulib-tool.m4
Copying file m4/manywarnings-c++.m4
Copying file m4/nanosleep.m4
Copying file m4/warn-on-use.m4
Copying file m4/wint_t.m4
Creating m4/gnulib-cache.m4
Updating m4/gnulib-comp.m4 (backup in m4/gnulib-comp.m4~)
Updating lib/gnulib.mk.in (backup in lib/gnulib.mk.in~)
Finished.
You may need to add #include directives for the following .h files.
#include <alloca.h>
#include <byteswap.h>
#include <dirent.h>
#include <execinfo.h>
#include <fcntl.h>
#include <getopt.h>
#include <gmp.h>
#include <ieee754.h>
#include <inttypes.h>
#include <regex.h>
#include <signal.h>
#include <stdalign.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/random.h>
#include <sys/select.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <time.h>
#include <unistd.h>
#include "acl.h"
#include "binary-io.h"
#include "c-ctype.h"
#include "c-strcase.h"
#include "careadlinkat.h"
#include "close-stream.h"
#include "count-leading-zeros.h"
#include "count-one-bits.h"
#include "count-trailing-zeros.h"
#include "diffseq.h"
#include "filemode.h"
#include "filename.h"
#include "filevercmp.h"
#include "fsusage.h"
#include "ftoastr.h"
#include "ignore-value.h"
#include "intprops.h"
#include "md5.h"
#include "minmax.h"
#include "nproc.h"
#include "pathmax.h"
#include "sha1.h"
#include "sha256.h"
#include "sha512.h"
#include "sig2str.h"
#include "stat-time.h"
#include "strftime.h"
#include "tempname.h"
#include "timespec.h"
#include "unlocked-io.h"
#include <sys/types.h>
#if HAVE_SYS_SOCKET_H
# include <sys/socket.h>
#elif HAVE_WS2TCPIP_H
# include <ws2tcpip.h>
#endif
You may need to use the following Makefile variables when linking.
Use them in <program>_LDADD when linking a program, or
in <library>_a_LDFLAGS or <library>_la_LDFLAGS when linking a library.
$(GETLOADAVG_LIBS)
$(LIBTHREAD)
$(LIB_ACL)
$(LIB_CLOCK_GETTIME)
$(LIB_CRYPTO)
$(LIB_EACCESS)
$(LIB_EXECINFO)
$(LIB_GETRANDOM)
$(LIB_HAS_ACL)
$(LIB_MBRTOWC)
$(LIB_NANOSLEEP)
$(LIB_PTHREAD_SIGMASK)
$(LIB_SELECT)
$(LIB_TIMER_TIME)
$(LTLIBGMP) when linking with libtool, $(LIBGMP) otherwise
$(LTLIBINTL) when linking with libtool, $(LIBINTL) otherwise
Don't forget to
- "include gnulib.mk.in" from within "lib/Makefile.am",
- mention "-I m4" in ACLOCAL_AMFLAGS in Makefile.am
or add an AC_CONFIG_MACRO_DIRS([m4]) invocation in ./configure.ac,
- mention "m4/gnulib-cache.m4" in EXTRA_DIST in Makefile.am,
- invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC,
- invoke gl_INIT in ./configure.ac.
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65) ... ok
Your system has the required tools.
Building aclocal.m4 ...
Running 'autoreconf -fi -I m4' ...
You can now run './configure'.
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: admin/merge-gnulib
modified: lib/gnulib.mk.in
modified: m4/gnulib-comp.m4
Untracked files:
(use "git add <file>..." to include in what will be committed)
lib/nanosleep.c
m4/nanosleep.m4
merge-gnulib.diff
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout -b for-larsi
Switched to a new branch 'for-larsi'
$ git add lib/nanosleep.c m4/nanosleep.m4 admin/merge-gnulib
lib/gnulib.mk.in m4/gnulib-comp.m4
$ git commit -m'Add Gnulib nanosleep module'
[for-larsi 2020d4fc91] Add Gnulib nanosleep module
5 files changed, 355 insertions(+), 1 deletion(-)
create mode 100644 lib/nanosleep.c
create mode 100644 m4/nanosleep.m4
$ git format-patch -1
0001-Add-Gnulib-nanosleep-module.patch
$
[0001-Add-Gnulib-nanosleep-module.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 03 Mar 2022 13:47:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> This diff is wrong, as it omits a line
> "GL_COND_OBJ_NANOSLEEP_CONDITION = @GL_COND_OBJ_NANOSLEEP_CONDITION@".
Yup, looks like it.
> I ran what should have been something like your commands and got the
> attached patch. One way forward is for you to simply install the
> attached patch and move on from there. Or we can continue to look into
> why things work for me and not for you. I suppose it could be an
> Autoconf bug on your platform, but it'd be an odd one.
As far as I can tell, I'm running exactly the same commands you are, but
I end up with a result that misses the line up there.
Let's see... I've been doing this on my development laptop (which uses
debian/bookworm (i.e., "testing"). I now re-ran the merge-gnulib on a
debian/bullseye (i.e., "stable"), and I get the same results as you now
(i.e., things work).
So either there's something weird on my laptop, or it sounds like
there's an Autoconf bug in debian/bookworm?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 03 Mar 2022 13:50:02 GMT)
Full text and
rfc822 format available.
Message #133 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Eli, here's the proposed complete patch to do some sleeping in
gnutls_try_handshake. Does it work on Windows for you?
diff --git a/admin/merge-gnulib b/admin/merge-gnulib
index fec469c017..ea3d23686f 100755
--- a/admin/merge-gnulib
+++ b/admin/merge-gnulib
@@ -40,7 +40,7 @@ GNULIB_MODULES=
getloadavg getopt-gnu getrandom gettime gettimeofday gitlog-to-changelog
ieee754-h ignore-value intprops largefile libgmp lstat
manywarnings memmem-simple mempcpy memrchr minmax mkostemp mktime
- nproc nstrftime
+ nanosleep nproc nstrftime
pathmax pipe2 pselect pthread_sigmask
qcopy-acl readlink readlinkat regex
sig2str sigdescr_np socklen stat-time std-gnu11 stdalign stddef stdio
diff --git a/lib/gnulib.mk.in b/lib/gnulib.mk.in
index 3a9f5b9818..3deeca98be 100644
--- a/lib/gnulib.mk.in
+++ b/lib/gnulib.mk.in
@@ -129,6 +129,7 @@
# minmax \
# mkostemp \
# mktime \
+# nanosleep \
# nproc \
# nstrftime \
# pathmax \
@@ -207,6 +208,7 @@ CPP = @CPP@
CPPFLAGS = @CPPFLAGS@
CRYPTOLIB = @CRYPTOLIB@
CXX = @CXX@
+CXXCPP = @CXXCPP@
CXXFLAGS = @CXXFLAGS@
CYGWIN_OBJ = @CYGWIN_OBJ@
C_SWITCH_MACHINE = @C_SWITCH_MACHINE@
@@ -283,6 +285,7 @@ GL_COND_OBJ_MEMPCPY_CONDITION = @GL_COND_OBJ_MEMPCPY_CONDITION@
GL_COND_OBJ_MEMRCHR_CONDITION = @GL_COND_OBJ_MEMRCHR_CONDITION@
GL_COND_OBJ_MINI_GMP_GNULIB_CONDITION = @GL_COND_OBJ_MINI_GMP_GNULIB_CONDITION@
GL_COND_OBJ_MKOSTEMP_CONDITION = @GL_COND_OBJ_MKOSTEMP_CONDITION@
+GL_COND_OBJ_NANOSLEEP_CONDITION = @GL_COND_OBJ_NANOSLEEP_CONDITION@
GL_COND_OBJ_OPEN_CONDITION = @GL_COND_OBJ_OPEN_CONDITION@
GL_COND_OBJ_PSELECT_CONDITION = @GL_COND_OBJ_PSELECT_CONDITION@
GL_COND_OBJ_PTHREAD_SIGMASK_CONDITION = @GL_COND_OBJ_PTHREAD_SIGMASK_CONDITION@
@@ -2497,6 +2500,16 @@ EXTRA_libgnu_a_SOURCES += mktime.c
endif
## end gnulib module mktime-internal
+## begin gnulib module nanosleep
+ifeq (,$(OMIT_GNULIB_MODULE_nanosleep))
+
+ifneq (,$(GL_COND_OBJ_NANOSLEEP_CONDITION))
+libgnu_a_SOURCES += nanosleep.c
+endif
+
+endif
+## end gnulib module nanosleep
+
## begin gnulib module nproc
ifeq (,$(OMIT_GNULIB_MODULE_nproc))
diff --git a/lib/nanosleep.c b/lib/nanosleep.c
new file mode 100644
index 0000000000..446794edc0
--- /dev/null
+++ b/lib/nanosleep.c
@@ -0,0 +1,195 @@
+/* Provide a replacement for the POSIX nanosleep function.
+
+ Copyright (C) 1999-2000, 2002, 2004-2022 Free Software Foundation, Inc.
+
+ This file is free software: you can redistribute it and/or modify
+ it under the terms of the GNU Lesser General Public License as
+ published by the Free Software Foundation; either version 2.1 of the
+ License, or (at your option) any later version.
+
+ This file is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with this program. If not, see <https://www.gnu.org/licenses/>. */
+
+/* written by Jim Meyering
+ and Bruno Haible for the native Windows part */
+
+#include <config.h>
+
+#include <time.h>
+
+#include "intprops.h"
+#include "verify.h"
+
+#include <stdbool.h>
+#include <stdio.h>
+#include <sys/types.h>
+#include <sys/select.h>
+#include <signal.h>
+
+#include <errno.h>
+
+#include <unistd.h>
+
+
+enum { BILLION = 1000 * 1000 * 1000 };
+
+#if HAVE_BUG_BIG_NANOSLEEP
+
+int
+nanosleep (const struct timespec *requested_delay,
+ struct timespec *remaining_delay)
+# undef nanosleep
+{
+ /* nanosleep mishandles large sleeps due to internal overflow problems.
+ The worst known case of this is Linux 2.6.9 with glibc 2.3.4, which
+ can't sleep more than 24.85 days (2^31 milliseconds). Similarly,
+ cygwin 1.5.x, which can't sleep more than 49.7 days (2^32 milliseconds).
+ Solve this by breaking the sleep up into smaller chunks. */
+
+ if (requested_delay->tv_nsec < 0 || BILLION <= requested_delay->tv_nsec)
+ {
+ errno = EINVAL;
+ return -1;
+ }
+
+ {
+ /* Verify that time_t is large enough. */
+ verify (TYPE_MAXIMUM (time_t) / 24 / 24 / 60 / 60);
+ const time_t limit = 24 * 24 * 60 * 60;
+ time_t seconds = requested_delay->tv_sec;
+ struct timespec intermediate;
+ intermediate.tv_nsec = requested_delay->tv_nsec;
+
+ while (limit < seconds)
+ {
+ int result;
+ intermediate.tv_sec = limit;
+ result = nanosleep (&intermediate, remaining_delay);
+ seconds -= limit;
+ if (result)
+ {
+ if (remaining_delay)
+ remaining_delay->tv_sec += seconds;
+ return result;
+ }
+ intermediate.tv_nsec = 0;
+ }
+ intermediate.tv_sec = seconds;
+ return nanosleep (&intermediate, remaining_delay);
+ }
+}
+
+#elif defined _WIN32 && ! defined __CYGWIN__
+/* Native Windows platforms. */
+
+# define WIN32_LEAN_AND_MEAN
+# include <windows.h>
+
+/* The Windows API function Sleep() has a resolution of about 15 ms and takes
+ at least 5 ms to execute. We use this function for longer time periods.
+ Additionally, we use busy-looping over short time periods, to get a
+ resolution of about 0.01 ms. In order to measure such short timespans,
+ we use the QueryPerformanceCounter() function. */
+
+int
+nanosleep (const struct timespec *requested_delay,
+ struct timespec *remaining_delay)
+{
+ static bool initialized;
+ /* Number of performance counter increments per nanosecond,
+ or zero if it could not be determined. */
+ static double ticks_per_nanosecond;
+
+ if (requested_delay->tv_nsec < 0 || BILLION <= requested_delay->tv_nsec)
+ {
+ errno = EINVAL;
+ return -1;
+ }
+
+ /* For requested delays of one second or more, 15ms resolution is
+ sufficient. */
+ if (requested_delay->tv_sec == 0)
+ {
+ if (!initialized)
+ {
+ /* Initialize ticks_per_nanosecond. */
+ LARGE_INTEGER ticks_per_second;
+
+ if (QueryPerformanceFrequency (&ticks_per_second))
+ ticks_per_nanosecond =
+ (double) ticks_per_second.QuadPart / 1000000000.0;
+
+ initialized = true;
+ }
+ if (ticks_per_nanosecond)
+ {
+ /* QueryPerformanceFrequency worked. We can use
+ QueryPerformanceCounter. Use a combination of Sleep and
+ busy-looping. */
+ /* Number of milliseconds to pass to the Sleep function.
+ Since Sleep can take up to 8 ms less or 8 ms more than requested
+ (or maybe more if the system is loaded), we subtract 10 ms. */
+ int sleep_millis = (int) requested_delay->tv_nsec / 1000000 - 10;
+ /* Determine how many ticks to delay. */
+ LONGLONG wait_ticks = requested_delay->tv_nsec * ticks_per_nanosecond;
+ /* Start. */
+ LARGE_INTEGER counter_before;
+ if (QueryPerformanceCounter (&counter_before))
+ {
+ /* Wait until the performance counter has reached this value.
+ We don't need to worry about overflow, because the performance
+ counter is reset at reboot, and with a frequency of 3.6E6
+ ticks per second 63 bits suffice for over 80000 years. */
+ LONGLONG wait_until = counter_before.QuadPart + wait_ticks;
+ /* Use Sleep for the longest part. */
+ if (sleep_millis > 0)
+ Sleep (sleep_millis);
+ /* Busy-loop for the rest. */
+ for (;;)
+ {
+ LARGE_INTEGER counter_after;
+ if (!QueryPerformanceCounter (&counter_after))
+ /* QueryPerformanceCounter failed, but succeeded earlier.
+ Should not happen. */
+ break;
+ if (counter_after.QuadPart >= wait_until)
+ /* The requested time has elapsed. */
+ break;
+ }
+ goto done;
+ }
+ }
+ }
+ /* Implementation for long delays and as fallback. */
+ Sleep (requested_delay->tv_sec * 1000 + requested_delay->tv_nsec / 1000000);
+
+ done:
+ /* Sleep is not interruptible. So there is no remaining delay. */
+ if (remaining_delay != NULL)
+ {
+ remaining_delay->tv_sec = 0;
+ remaining_delay->tv_nsec = 0;
+ }
+ return 0;
+}
+
+#else
+/* Other platforms lacking nanosleep.
+ It's not clear whether these are still practical porting targets.
+ For now, just fall back on pselect. */
+
+/* Suspend execution for at least *REQUESTED_DELAY seconds. The
+ *REMAINING_DELAY part isn't implemented yet. */
+
+int
+nanosleep (const struct timespec *requested_delay,
+ struct timespec *remaining_delay)
+{
+ return pselect (0, NULL, NULL, NULL, requested_delay, NULL);
+}
+#endif
diff --git a/m4/gnulib-comp.m4 b/m4/gnulib-comp.m4
index 1d31239d2d..fb5f1b52a4 100644
--- a/m4/gnulib-comp.m4
+++ b/m4/gnulib-comp.m4
@@ -140,6 +140,7 @@ AC_DEFUN
# Code from module mktime:
# Code from module mktime-internal:
# Code from module multiarch:
+ # Code from module nanosleep:
# Code from module nocrash:
# Code from module nproc:
# Code from module nstrftime:
@@ -430,6 +431,10 @@ AC_DEFUN
fi
gl_TIME_MODULE_INDICATOR([mktime])
gl_MULTIARCH
+ gl_FUNC_NANOSLEEP
+ gl_CONDITIONAL([GL_COND_OBJ_NANOSLEEP],
+ [test $HAVE_NANOSLEEP = 0 || test $REPLACE_NANOSLEEP = 1])
+ gl_TIME_MODULE_INDICATOR([nanosleep])
gl_NPROC
gl_FUNC_GNU_STRFTIME
gl_PATHMAX
@@ -1304,6 +1309,7 @@ AC_DEFUN
lib/mkostemp.c
lib/mktime-internal.h
lib/mktime.c
+ lib/nanosleep.c
lib/nproc.c
lib/nproc.h
lib/nstrftime.c
@@ -1456,6 +1462,7 @@ AC_DEFUN
m4/mktime.m4
m4/mode_t.m4
m4/multiarch.m4
+ m4/nanosleep.m4
m4/nocrash.m4
m4/nproc.m4
m4/nstrftime.m4
diff --git a/m4/nanosleep.m4 b/m4/nanosleep.m4
new file mode 100644
index 0000000000..1964b1ea47
--- /dev/null
+++ b/m4/nanosleep.m4
@@ -0,0 +1,139 @@
+# serial 41
+
+dnl From Jim Meyering.
+dnl Check for the nanosleep function.
+dnl If not found, use the supplied replacement.
+dnl
+
+# Copyright (C) 1999-2001, 2003-2022 Free Software Foundation, Inc.
+
+# This file is free software; the Free Software Foundation
+# gives unlimited permission to copy and/or distribute it,
+# with or without modifications, as long as this notice is preserved.
+
+AC_DEFUN([gl_FUNC_NANOSLEEP],
+[
+ AC_REQUIRE([gl_TIME_H_DEFAULTS])
+ AC_REQUIRE([AC_CANONICAL_HOST]) dnl for cross-compiles
+
+ dnl Persuade glibc and Solaris <time.h> to declare nanosleep.
+ AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
+
+ AC_CHECK_DECLS_ONCE([alarm])
+
+ nanosleep_save_libs=$LIBS
+
+ # Solaris 2.5.1 needs -lposix4 to get the nanosleep function.
+ # Solaris 7 prefers the library name -lrt to the obsolescent name -lposix4.
+ LIB_NANOSLEEP=
+ AC_SUBST([LIB_NANOSLEEP])
+ AC_SEARCH_LIBS([nanosleep], [rt posix4],
+ [test "$ac_cv_search_nanosleep" = "none required" ||
+ LIB_NANOSLEEP=$ac_cv_search_nanosleep])
+ if test "x$ac_cv_search_nanosleep" != xno; then
+ dnl The system has a nanosleep function.
+
+ AC_REQUIRE([gl_MULTIARCH])
+ if test $APPLE_UNIVERSAL_BUILD = 1; then
+ # A universal build on Apple Mac OS X platforms.
+ # The test result would be 'no (mishandles large arguments)' in 64-bit
+ # mode but 'yes' in 32-bit mode. But we need a configuration result that
+ # is valid in both modes.
+ gl_cv_func_nanosleep='no (mishandles large arguments)'
+ fi
+
+ AC_CACHE_CHECK([for working nanosleep],
+ [gl_cv_func_nanosleep],
+ [
+ AC_RUN_IFELSE(
+ [AC_LANG_SOURCE([[
+ #include <errno.h>
+ #include <limits.h>
+ #include <signal.h>
+ #include <time.h>
+ #include <unistd.h>
+ #define TYPE_SIGNED(t) (! ((t) 0 < (t) -1))
+ #define TYPE_MAXIMUM(t) \
+ ((t) (! TYPE_SIGNED (t) \
+ ? (t) -1 \
+ : ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 1)))
+
+ #if HAVE_DECL_ALARM
+ static void
+ check_for_SIGALRM (int sig)
+ {
+ if (sig != SIGALRM)
+ _exit (1);
+ }
+ #endif
+
+ int
+ main ()
+ {
+ static struct timespec ts_sleep;
+ static struct timespec ts_remaining;
+ /* Test for major problems first. */
+ if (! nanosleep)
+ return 2;
+ ts_sleep.tv_sec = 0;
+ ts_sleep.tv_nsec = 1;
+ #if HAVE_DECL_ALARM
+ {
+ static struct sigaction act;
+ act.sa_handler = check_for_SIGALRM;
+ sigemptyset (&act.sa_mask);
+ sigaction (SIGALRM, &act, NULL);
+ alarm (1);
+ if (nanosleep (&ts_sleep, NULL) != 0)
+ return 3;
+ /* Test for a minor problem: the handling of large arguments. */
+ ts_sleep.tv_sec = TYPE_MAXIMUM (time_t);
+ ts_sleep.tv_nsec = 999999999;
+ alarm (1);
+ if (nanosleep (&ts_sleep, &ts_remaining) != -1)
+ return 4;
+ if (errno != EINTR)
+ return 5;
+ if (ts_remaining.tv_sec <= TYPE_MAXIMUM (time_t) - 10)
+ return 6;
+ }
+ #else /* A simpler test for native Windows. */
+ if (nanosleep (&ts_sleep, &ts_remaining) < 0)
+ return 3;
+ #endif
+ return 0;
+ }]])],
+ [gl_cv_func_nanosleep=yes],
+ [case $? in dnl (
+ 4|5|6) gl_cv_func_nanosleep='no (mishandles large arguments)';; dnl (
+ *) gl_cv_func_nanosleep=no;;
+ esac],
+ [case "$host_os" in dnl ((
+ linux*) # Guess it halfway works when the kernel is Linux.
+ gl_cv_func_nanosleep='guessing no (mishandles large arguments)' ;;
+ mingw*) # Guess no on native Windows.
+ gl_cv_func_nanosleep='guessing no' ;;
+ *) # If we don't know, obey --enable-cross-guesses.
+ gl_cv_func_nanosleep="$gl_cross_guess_normal" ;;
+ esac
+ ])
+ ])
+ case "$gl_cv_func_nanosleep" in
+ *yes)
+ REPLACE_NANOSLEEP=0
+ ;;
+ *)
+ REPLACE_NANOSLEEP=1
+ case "$gl_cv_func_nanosleep" in
+ *"mishandles large arguments"*)
+ AC_DEFINE([HAVE_BUG_BIG_NANOSLEEP], [1],
+ [Define to 1 if nanosleep mishandles large arguments.])
+ ;;
+ esac
+ ;;
+ esac
+ else
+ HAVE_NANOSLEEP=0
+ fi
+ LIBS=$nanosleep_save_libs
+])
diff --git a/src/gnutls.c b/src/gnutls.c
index 3ec3837067..09590ca005 100644
--- a/src/gnutls.c
+++ b/src/gnutls.c
@@ -616,6 +616,9 @@ gnutls_try_handshake (struct Lisp_Process *proc)
gnutls_session_t state = proc->gnutls_state;
int ret;
bool non_blocking = proc->is_non_blocking_client;
+ /* Sleep for ten milliseconds when busy-looping in
+ gnutls_handshake. */
+ struct timespec delay = { 0, 1000 * 1000 * 10 };
if (proc->gnutls_complete_negotiation_p)
non_blocking = false;
@@ -630,6 +633,7 @@ gnutls_try_handshake (struct Lisp_Process *proc)
maybe_quit ();
if (non_blocking && ret != GNUTLS_E_INTERRUPTED)
break;
+ nanosleep (&delay, NULL);
}
proc->gnutls_initstage = GNUTLS_STAGE_HANDSHAKE_TRIED;
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 03 Mar 2022 15:12:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: bug-gnulib <at> gnu.org, npostavs <at> gmail.com, 32452 <at> debbugs.gnu.org, Eli
> Zaretskii <eliz <at> gnu.org>
> Date: Thu, 03 Mar 2022 14:49:18 +0100
>
> Eli, here's the proposed complete patch to do some sleeping in
> gnutls_try_handshake. Does it work on Windows for you?
It does, after I make these 2 additional changes:
diff --git a/nt/gnulib-cfg.mk b/nt/gnulib-cfg.mk
index 4748474..69119b1 100644
--- a/nt/gnulib-cfg.mk
+++ b/nt/gnulib-cfg.mk
@@ -74,3 +74,4 @@ OMIT_GNULIB_MODULE_futimens =
OMIT_GNULIB_MODULE_utimensat = true
OMIT_GNULIB_MODULE_file-has-acl = true
OMIT_GNULIB_MODULE_nproc = true
+OMIT_GNULIB_MODULE_nanosleep = true
diff --git a/nt/mingw-cfg.site b/nt/mingw-cfg.site
index 6ab81e9..7ca19cb 100644
--- a/nt/mingw-cfg.site
+++ b/nt/mingw-cfg.site
@@ -167,3 +167,6 @@ ac_cv_func_strsignal=no
# implementation of 'free' doesn't touch errno, and it emits a
# compilation warning.
gl_cv_func_free_preserves_errno=yes
+# Don't build the Gnulib nanosleep module: it requires W2K or later,
+# and MinGW does have nanosleep.
+gl_cv_func_nanosleep=yes
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Thu, 03 Mar 2022 21:41:02 GMT)
Full text and
rfc822 format available.
Message #139 received at 32452 <at> debbugs.gnu.org (full text, mbox):
On 3/3/22 05:46, Lars Ingebrigtsen wrote:
> So either there's something weird on my laptop, or it sounds like
> there's an Autoconf bug in debian/bookworm?
Could be either.
Debian Bookworm uses Autoconf 2.71+patches, as opposed to the Autoconf
2.69+patches that Fedora 35 uses. For what it's worth I just now tried
to reproduce the problem on Fedora 35 but with an Autoconf 2.71 that I
installed by hand, and could not reproduce the problem. However, I
looked at the patches in autoconf_2.71-2.debian.tar.xz and none of them
seemed to be relevant (some don't even apply, which is curious....).
If you have an easily-reproducible script (runs in the C locale, etc.)
it might be worth a bug report to the Debian developers. To be honest
though it sounds like it might be something odd on your laptop.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 04 Mar 2022 15:29:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> It does, after I make these 2 additional changes:
Thanks; I've now pushed this complete change set to Emacs 29. I'll open
a new bug report for the p/select issue Paul noted on gnustep, and I'm
closing this one.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
32452 <at> debbugs.gnu.org and Noam Postavsky <npostavs <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Fri, 04 Mar 2022 15:29:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 04 Mar 2022 15:32:01 GMT)
Full text and
rfc822 format available.
Message #147 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> If you have an easily-reproducible script (runs in the C locale, etc.)
> it might be worth a bug report to the Debian developers. To be honest
> though it sounds like it might be something odd on your laptop.
Might well be -- perhaps something's gotten slightly borked while doing
updates. So I think I'll just leave this be for now...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 04 Mar 2022 16:49:02 GMT)
Full text and
rfc822 format available.
Message #150 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Hm, this led to the emacs-module tests to fail:
passed 16/38 mod-test-non-local-exit-throw-test (0.000024 sec)
../src/emacs: symbol lookup error: /home/larsi/src/emacs/trunk/test/src/emacs-module-resources/mod-test.so: undefined symbol: rpl_nanosleep
make[1]: *** [Makefile:176: src/emacs-module-tests.log] Error 127
Does gnulib changes require updates to the module stuff?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Fri, 04 Mar 2022 19:48:02 GMT)
Full text and
rfc822 format available.
Message #153 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eggert <at> cs.ucla.edu, npostavs <at> gmail.com, 32452 <at> debbugs.gnu.org
> Date: Fri, 04 Mar 2022 17:47:48 +0100
>
> Hm, this led to the emacs-module tests to fail:
>
> passed 16/38 mod-test-non-local-exit-throw-test (0.000024 sec)
> ../src/emacs: symbol lookup error: /home/larsi/src/emacs/trunk/test/src/emacs-module-resources/mod-test.so: undefined symbol: rpl_nanosleep
> make[1]: *** [Makefile:176: src/emacs-module-tests.log] Error 127
>
> Does gnulib changes require updates to the module stuff?
mod-test.c calls nanosleep, so it needs to be linked against libgnu.a,
I think. (We should have done that to begin with, since mod-test.c
includes config.h and headers that have Gnulib replacements.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Sat, 05 Mar 2022 17:12:01 GMT)
Full text and
rfc822 format available.
Message #156 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> mod-test.c calls nanosleep, so it needs to be linked against libgnu.a,
> I think. (We should have done that to begin with, since mod-test.c
> includes config.h and headers that have Gnulib replacements.)
The following seems to do the trick (and simplifies the rule slightly).
Does this look correct to you?
diff --git a/test/Makefile.in b/test/Makefile.in
index 708c4b2fb0..09f1e0f005 100644
--- a/test/Makefile.in
+++ b/test/Makefile.in
@@ -283,9 +283,9 @@ $(test_module): $(test_module:
$(AM_V_CCLD)${MKDIR_P} $(dir $@)
$(AM_V_at)$(CC) -shared $(CPPFLAGS) $(MODULE_CFLAGS) $(LDFLAGS) \
-o $@ $< $(LIBGMP) \
+ ../lib/libgnu.a \
$(and $(GMP_H),$(srcdir)/../lib/mini-gmp-gnulib.c) \
- $(FREE_SOURCE_$(REPLACE_FREE)) \
- $(srcdir)/../lib/timespec.c $(srcdir)/../lib/gettime.c
+ $(FREE_SOURCE_$(REPLACE_FREE))
endif
src/emacs-tests.log: ../lib-src/seccomp-filter.c
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Sat, 05 Mar 2022 17:48:01 GMT)
Full text and
rfc822 format available.
Message #159 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eggert <at> cs.ucla.edu, npostavs <at> gmail.com, 32452 <at> debbugs.gnu.org
> Date: Sat, 05 Mar 2022 18:11:33 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > mod-test.c calls nanosleep, so it needs to be linked against libgnu.a,
> > I think. (We should have done that to begin with, since mod-test.c
> > includes config.h and headers that have Gnulib replacements.)
>
> The following seems to do the trick (and simplifies the rule slightly).
> Does this look correct to you?
>
> diff --git a/test/Makefile.in b/test/Makefile.in
> index 708c4b2fb0..09f1e0f005 100644
> --- a/test/Makefile.in
> +++ b/test/Makefile.in
> @@ -283,9 +283,9 @@ $(test_module): $(test_module:
> $(AM_V_CCLD)${MKDIR_P} $(dir $@)
> $(AM_V_at)$(CC) -shared $(CPPFLAGS) $(MODULE_CFLAGS) $(LDFLAGS) \
> -o $@ $< $(LIBGMP) \
> + ../lib/libgnu.a \
> $(and $(GMP_H),$(srcdir)/../lib/mini-gmp-gnulib.c) \
> - $(FREE_SOURCE_$(REPLACE_FREE)) \
> - $(srcdir)/../lib/timespec.c $(srcdir)/../lib/gettime.c
> + $(FREE_SOURCE_$(REPLACE_FREE))
> endif
I'd put libgnu.a last, after all the sources. It's safer, since ld is
a one-pass linker, so it needs to see the libraries after it saw all
the sources.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Sat, 05 Mar 2022 18:07:02 GMT)
Full text and
rfc822 format available.
Message #162 received at 32452 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I'd put libgnu.a last, after all the sources. It's safer, since ld is
> a one-pass linker, so it needs to see the libraries after it saw all
> the sources.
Makes sense; now pushed to the trunk.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32452
; Package
emacs
.
(Wed, 09 Mar 2022 03:02:01 GMT)
Full text and
rfc822 format available.
Message #165 received at 32452 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 3/5/22 09:11, Lars Ingebrigtsen wrote:
> $(AM_V_at)$(CC) -shared $(CPPFLAGS) $(MODULE_CFLAGS) $(LDFLAGS) \
> -o $@ $< $(LIBGMP) \
> + ../lib/libgnu.a \
Unfortunately that won't work in general; the comment for mod-test.so
says "In the compilation command, we can't use any object or archive
file as source because those are not compiled with -fPIC" but as things
stood mod-test.so was being linked with libgnu.a.
Anyway, mod-test.so should be decoupled from Emacs as much as possible -
that's the whole point of modules after all - so the mod-test.so rule
shouldn't make assumptions about how Emacs internals use Gnulib. I
installed the attached patches to lessen the coupling between
mod-test.so and Emacs internals and I hope this fixes the problem. It
may need to be adjusted a tad for platforms that lack
nanosleep/clock_gettime/libgmp whatever, but the basic idea should work
on these platforms with only minor twiddling.
Even with these patches, mod-test.so uses "config.h"; but at least it
doesn't use Gnulib code.
[0001-Do-not-include-attribute.h-from-config.h.patch (text/x-patch, attachment)]
[0002-Decouple-mod-test.c-from-Gnulib.patch (text/x-patch, attachment)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 06 Apr 2022 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 26 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.