On Feb 26 20:08, Dimitry Andric via Cygwin wrote:
> On 26 Feb 2024, at 20:03, Corinna Vinschen wrote:
> >
> > On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
> >> Hi,
> >>
> >> After a recent upgrade of a Cygwin installation, including cygwin1.dll
>
On 26 Feb 2024, at 20:03, Corinna Vinschen wrote:
>
> On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
>> Hi,
>>
>> After a recent upgrade of a Cygwin installation, including cygwin1.dll
>> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
On Feb 26 17:34, Dimitry Andric via Cygwin wrote:
> Hi,
>
> After a recent upgrade of a Cygwin installation, including cygwin1.dll
> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's co
i,
>>>> After a recent upgrade of a Cygwin installation, including cygwin1.dll
>>>> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
>>>> 3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
>>>> GNU make 4.4
On 26/02/2024 18:16, Dimitry Andric via Cygwin wrote:
On 26 Feb 2024, at 18:00, Marco Atzeri via Cygwin wrote:
On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote:
Hi,
After a recent upgrade of a Cygwin installation, including cygwin1.dll
(see https://cygwin.com/pipermail/cygwin/2024
On 26 Feb 2024, at 18:00, Marco Atzeri via Cygwin wrote:
>
> On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote:
>> Hi,
>> After a recent upgrade of a Cygwin installation, including cygwin1.dll
>> (see https://cygwin.com/pipermail/cygwin/2024-February/255308.html)
On 26/02/2024 17:34, Dimitry Andric via Cygwin wrote:
Hi,
After a recent upgrade of a Cygwin installation, including cygwin1.dll
(see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
GNU make 4.4
Hi,
After a recent upgrade of a Cygwin installation, including cygwin1.dll
(see https://cygwin.com/pipermail/cygwin/2024-February/255308.html) to
3.5.0-1, I now get spurious "error 127" messages from (Cygwin's copy of)
GNU make 4.4.1-2, when it starts external processes and thos
On 2024-01-24 05:11, Corinna Vinschen via Cygwin wrote:
> Is anybody willing to give this a whirl? We have a good year until
> the next major release...
As far as the problem of not allocating per-mutex kernel objects,
this can be done by implementing futex.
Linux has futexes, mainly for
On 2024-01-24 03:55, Takashi Yano via Cygwin wrote:
> Are there any code examples that use PTHREAD_MUTEX_INITIALIZER
> with pthread_mutex_destroy()?
I don't think I've seen one.
I think they are rare in the field, precisely because
PTHREAD_MUTEX_INITIALIZER is mainly used in C code to
On Jan 24 14:05, Corinna Vinschen via Cygwin wrote:
> On Jan 24 20:55, Takashi Yano via Cygwin wrote:
> > On Mon, 22 Jan 2024 19:24:52 -0800
> > Kaz Kylheku wrote:
> > > In real systems, the static distinction has no meaning.
> > >
> > > This code can be inside a shared library:
> > >
> > >
On Jan 24 20:55, Takashi Yano via Cygwin wrote:
> On Mon, 22 Jan 2024 19:24:52 -0800
> Kaz Kylheku wrote:
> > In real systems, the static distinction has no meaning.
> >
> > This code can be inside a shared library:
> >
> >static pthread_mutex_t g_lock = PTHREAD_MUTEX_INITIALIZER;
> >
> >
On Mon, 22 Jan 2024 19:24:52 -0800
Kaz Kylheku wrote:
> On 2024-01-19 20:18, Takashi Yano via Cygwin wrote:
> > And I tried to observe the pthread_mutex_xxx() call. Then found the
> > test case does like:
> >
> > #include
> > int main()
> > {
> > for (;;) {
> > pthread_mutex_t m =
On 2024-01-19 20:18, Takashi Yano via Cygwin wrote:
> And I tried to observe the pthread_mutex_xxx() call. Then found the
> test case does like:
>
> #include
> int main()
> {
> for (;;) {
> pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
> pthread_mutex_lock();
>
On Jan 22 13:41, ASSI via Cygwin wrote:
> Corinna Vinschen via Cygwin writes:
> > However, I don't find this in the standards. pthread_once is neither
> > one of the required cancellation points, nor one of the optional
> > cancellation points.
>
> The initializer can be cancellable per POSIX,
Corinna Vinschen via Cygwin writes:
> However, I don't find this in the standards. pthread_once is neither
> one of the required cancellation points, nor one of the optional
> cancellation points.
The initializer can be cancellable per POSIX, though:
"The pthread_once() function is not a
On Jan 22 20:16, Takashi Yano via Cygwin wrote:
> On Mon, 22 Jan 2024 10:57:48 +0100
> Corinna Vinschen wrote:
> > On Jan 22 10:25, Corinna Vinschen via Cygwin wrote:
> > > On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> > > > PATCH2: (for cygwin)
> > > > Avoid handle leak caused when non-static
On Jan 22 20:06, Takashi Yano via Cygwin wrote:
> On Mon, 22 Jan 2024 10:25:28 +0100
> Corinna Vinschen wrote:
> > On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> > > PATCH2: (for cygwin)
> > > Avoid handle leak caused when non-static pthread_once_t is initialized
> > > with PTHREAD_ONCE_INIT
>
On Mon, 22 Jan 2024 10:57:48 +0100
Corinna Vinschen wrote:
> On Jan 22 10:25, Corinna Vinschen via Cygwin wrote:
> > On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> > > PATCH2: (for cygwin)
> > > Avoid handle leak caused when non-static pthread_once_t is initialized
> > > with PTHREAD_ONCE_INIT
On Mon, 22 Jan 2024 10:25:28 +0100
Corinna Vinschen wrote:
> On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> > PATCH2: (for cygwin)
> > Avoid handle leak caused when non-static pthread_once_t is initialized
> > with PTHREAD_ONCE_INIT
> > diff --git a/winsup/cygwin/thread.cc
On Jan 22 10:25, Corinna Vinschen via Cygwin wrote:
> On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> > PATCH2: (for cygwin)
> > Avoid handle leak caused when non-static pthread_once_t is initialized
> > with PTHREAD_ONCE_INIT
> > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
>
On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> PATCH2: (for cygwin)
> Avoid handle leak caused when non-static pthread_once_t is initialized
> with PTHREAD_ONCE_INIT
> diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> index 7bb4f9fc8..127569160 100644
> ---
On Sun, 21 Jan 2024 14:30:00 +0100
ASSI wrote:
> Takashi Yano via Cygwin writes:
> > I found the cause. In pthread.h of cygwin, PTHREAD_ONCE_INIT is defined as:
> > #define PTHREAD_ONCE_INIT { PTHREAD_MUTEX_INITIALIZER, 0 }
> > however, libstdc++ initializes non-static pthread_once_t using this
Takashi Yano via Cygwin writes:
> I found the cause. In pthread.h of cygwin, PTHREAD_ONCE_INIT is defined as:
> #define PTHREAD_ONCE_INIT { PTHREAD_MUTEX_INITIALIZER, 0 }
> however, libstdc++ initializes non-static pthread_once_t using this macro.
Hi Corinna,
On Sat, 20 Jan 2024 21:24:27 +0900
Takashi Yano wrote:
> On Sat, 20 Jan 2024 10:13:22 +0100
> ASSI wrote:
> > Takashi Yano via Cygwin writes:
> > > I might find the culprit in gcc's libstdc++ code such as:
> > > libstdc++-v3/include/ext/concurrentce.h:
> > > class __mutex
> > > {
Takashi Yano via Cygwin writes:
>> So what happens if you undefine __GTHREAD_MUTEX_INIT?
>
> I have tried. The test case:
…and then rebuild libstdc++ of course.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf Blofeld V1.15B11:
On Sat, 20 Jan 2024 10:13:22 +0100
ASSI wrote:
> Takashi Yano via Cygwin writes:
> > I might find the culprit in gcc's libstdc++ code such as:
> > libstdc++-v3/include/ext/concurrentce.h:
> > class __mutex
> > {
> > private:
> > #if __GTHREADS && defined __GTHREAD_MUTEX_INIT
> >
Takashi Yano via Cygwin writes:
> I might find the culprit in gcc's libstdc++ code such as:
> libstdc++-v3/include/ext/concurrentce.h:
> class __mutex
> {
> private:
> #if __GTHREADS && defined __GTHREAD_MUTEX_INIT
> __gthread_mutex_t _M_mutex = __GTHREAD_MUTEX_INIT;
> #else
>
Hi Corinna and Achim,
On Sat, 20 Jan 2024 13:18:25 +0900
Takashi Yano wrote:
> Hi Corinna,
>
> On Fri, 19 Jan 2024 15:28:40 +0100
> Corinna Vinschen wrote:
> > On Jan 19 22:44, Takashi Yano via Cygwin wrote:
> > > Hi,
> > >
> > > I might find the bug
Hi Corinna,
On Fri, 19 Jan 2024 15:28:40 +0100
Corinna Vinschen wrote:
> On Jan 19 22:44, Takashi Yano via Cygwin wrote:
> > Hi,
> >
> > I might find the bug of cygwin1.dll (including 3.4.x, 3.5.0 (TEST)).
> > The following test case (c++ code) causes handl
On Jan 19 22:44, Takashi Yano via Cygwin wrote:
> Hi,
>
> I might find the bug of cygwin1.dll (including 3.4.x, 3.5.0 (TEST)).
> The following test case (c++ code) causes handle leak.
>
> This issue is reproducible with both g++ and clang++.
> However, it does not happen
Hi,
I might find the bug of cygwin1.dll (including 3.4.x, 3.5.0 (TEST)).
The following test case (c++ code) causes handle leak.
This issue is reproducible with both g++ and clang++.
However, it does not happen in Linux environment.
So I guess this is the cygwin1.dlll bug.
I looked
On 16/11/2023 15:50, Bill Sharp via Cygwin wrote:
On Thu, 16 Nov 2023 at 07:50, Brian Inglis via Cygwin
wrote:
On 2023-11-16 00:03, Martin Wege wrote:
This is not helpful. Cygwin setup-x86-64.exe not being able to update,
because SOMETHING is locking cygwin1.dll is in the top 50 of your
On 16/11/2023 07:03, Martin Wege via Cygwin wrote:
On Wed, Nov 15, 2023 at 6:05 PM Andrey Repin via Cygwin
wrote:
[...]
snip
Unable to extract /usr/bin/cygwin1.dll -- error writing file
snip
The fix is to do a $ sc stop cygserver # as Administrator, then
"
On Thu, 16 Nov 2023 at 07:50, Brian Inglis via Cygwin
wrote:
> On 2023-11-16 00:03, Martin Wege wrote:
> > This is not helpful. Cygwin setup-x86-64.exe not being able to update,
> > because SOMETHING is locking cygwin1.dll is in the top 50 of your IT
> > support, right fol
On 2023-11-16 00:03, Martin Wege wrote:
On Wed, Nov 15, 2023 at 6:05 PM Andrey Repin wrote:
The Cygwin installer "setup-x86_64.exe" has problems updating cygwin1.dll when
cygserver is running:
You should stop ALL Cygwin processes before starting setup.exe.
This is
On Wed, Nov 15, 2023 at 6:05 PM Andrey Repin via Cygwin
wrote:
>
> Greetings, Mainz, Roland!
>
>
> > Hi!
>
> >
>
> > The Cygwin installer "setup-x86_64.exe" has problems updating cygwin1.dll
> > when cygserver is running:
>
> You
Greetings, Mainz, Roland!
> Hi!
>
> The Cygwin installer "setup-x86_64.exe" has problems updating cygwin1.dll
> when cygserver is running:
You should stop ALL Cygwin processes before starting setup.exe.
This is documented.
> snip
> Unable to
Hi!
The Cygwin installer "setup-x86_64.exe" has problems updating cygwin1.dll when
cygserver is running:
snip
Unable to extract /usr/bin/cygwin1.dll -- error writing file
snip
The fix is to do a $ sc stop cygserver # as Administrator, then
"setup-
> Sorry, the second gdb command should be
> info line *__assert+0x42a4
> > (Note the change in symbol name: two "_" there)
>
I think it'd be easier to "catch" the problem rather than to chase it by
running all commands under the debugger.
For that, define the CYGWIN environment variable
Sorry, the second gdb command should be
info line *__assert+0x42a4
(Note the change in symbol name: two "_" there)
..mark
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe
Hi Derek,
Derek Pagel via Cygwin wrote:
We've had problems with slow Cygwin commands, so we were able to capture a
stack trace when the 'cp' program taking a long time to complete, and we
noticed in the stack trace that the last thing cygwin1.dll does is calls
assert. What might that suggest
We've had problems with slow Cygwin commands, so we were able to capture a
stack trace when the 'cp' program taking a long time to complete, and we
noticed in the stack trace that the last thing cygwin1.dll does is calls
assert. What might that suggest? And are there any situations that would
to include it in the distribution at all or such
that it will be in the same folder as cygwin1.dll.
If environment variable TERMINFO is set, cygncurses*.dll searches
terminfo from TERMINFO. So it is possible if you have chance to
set environment variable TERMINFO.
Please refer to 'man terminfo' for more d
t in the distribution at all or
> such that it will be in the same folder as cygwin1.dll.
If environment variable TERMINFO is set, cygncurses*.dll searches
terminfo from TERMINFO. So it is possible if you have chance to
set environment variable TERMINFO.
Please refer to 'man terminfo' for more detail.
, when trying to create a distributable zip file with all the
> > libraries included, something strange happens:
> > In order to allow users without a CygWin installation to start CoCoA 5, all
> > the required DLLs need to be distributed together with the application
> > itself
g strange happens:
> In order to allow users without a CygWin installation to start CoCoA 5, all
> the required DLLs need to be distributed together with the application itself.
> All the required libraries could be found using DependencyWalker and cygcheck.
> Of course, as expected,
with the application itself.
All the required libraries could be found using DependencyWalker and cygcheck.
Of course, as expected, cygwin1.dll is one of the required DLLs.
As soon as I place cygwin1.dll in the installation directory where CoCoA 5's
executable resides, readline support breaks.
For some
On 5/28/2022 10:20 AM, Takashi Yano wrote:
- After the commit 6d898f43, cygwin fails to start if cygwin1.dll
is placed in the root directory. This patch fixes the issue.
Addresses: https://cygwin.com/pipermail/cygwin/2022-May/251548.html
---
winsup/cygwin/cygheap.cc | 5 +
1 file
- After the commit 6d898f43, cygwin fails to start if cygwin1.dll
is placed in the root directory. This patch fixes the issue.
Addresses: https://cygwin.com/pipermail/cygwin/2022-May/251548.html
---
winsup/cygwin/cygheap.cc | 5 +
1 file changed, 5 insertions(+)
diff --git a/winsup/cygwin
gt;Details from
> > > Explorer). Is this by intent or a miss?
> > > It is breaking my application installer that relied on version check for
> > > cygwin1.dll.
>
> > Binaries should not have VersionInfo, only cygwin1.dll had it.
> > Not checked on 3.3.x
&
my application installer that relied on version check for
cygwin1.dll.
Binaries should not have VersionInfo, only cygwin1.dll had it.
Not checked on 3.3.x
Confirmed missing from cygwin.dll 3.3.0 64 and 32 bit and present up to
at least 3.2.1. Also present in some other DLLs:
cyg{asprintf,crypto,freet
>>From: Marco Atzeri
>>Date: Thu, 11 Nov 2021 20:26:15 +0100
>>Subject: Re: 3.3.1: Missing VersionInfo resource for all executables/DLLs
>>Binaries should not have VersionInfo, only cygwin1.dll had it.
>>Not checked on 3.3.x
Hello Marco,
Yes, you are cor
On Dec 3 10:58, Mattl Mario wrote:
> Hello everyone,
>
> I can confirm:
> with the latest snapshot-DLL, it is working fine again. (as Corinna mentioned)
Thanks for testing!
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Hello everyone,
I can confirm:
with the latest snapshot-DLL, it is working fine again. (as Corinna mentioned)
Many thanks
BR Mario
SSI Schäfer IT Solutions GmbH | Friesachstrasse 15 | 8114 Friesach | Austria
Registered Office: Friesach | Commercial Register: 49324 K | VAT no. ATU28654300
t; > > > Ken Brown via Cygwin wrote:
> > > > > On 12/1/2020 4:24 AM, Mattl Mario wrote:
> > > > > > Hello,
> > > > > >
> > > > > > Since cygwin1.dll version 3.1.5, I observed the following behavior:
> > > &
On 12/1/2020 4:24 AM, Mattl Mario wrote:
> > > > > Hello,
> > > > >
> > > > > Since cygwin1.dll version 3.1.5, I observed the following behavior:
> > > > > If a symbolic link is existing in the PATH environment, programs
> > > > > (ex
On Dec 2 15:05, Corinna Vinschen wrote:
> On Dec 2 13:39, Takashi Yano via Cygwin wrote:
> > On Tue, 1 Dec 2020 19:13:39 -0500
> > Ken Brown via Cygwin wrote:
> > > On 12/1/2020 4:24 AM, Mattl Mario wrote:
> > > > Hello,
> > > >
> > > &g
0 4:24 AM, Mattl Mario wrote:
> > > > > Hello,
> > > > >
> > > > > Since cygwin1.dll version 3.1.5, I observed the following behavior:
> > > > > If a symbolic link is existing in the PATH environment, programs
> > > > > (exter
Am 02.12.2020 um 15:05 schrieb Corinna Vinschen:
On Dec 2 13:39, Takashi Yano via Cygwin wrote:
On Tue, 1 Dec 2020 19:13:39 -0500
Ken Brown via Cygwin wrote:
On 12/1/2020 4:24 AM, Mattl Mario wrote:
Hello,
Since cygwin1.dll version 3.1.5, I observed the following behavior:
If a symbolic
On Dec 2 13:39, Takashi Yano via Cygwin wrote:
> On Tue, 1 Dec 2020 19:13:39 -0500
> Ken Brown via Cygwin wrote:
> > On 12/1/2020 4:24 AM, Mattl Mario wrote:
> > > Hello,
> > >
> > > Since cygwin1.dll version 3.1.5, I observed the following behavio
On Tue, 1 Dec 2020 19:13:39 -0500
Ken Brown via Cygwin wrote:
> On 12/1/2020 4:24 AM, Mattl Mario wrote:
> > Hello,
> >
> > Since cygwin1.dll version 3.1.5, I observed the following behavior:
> > If a symbolic link is existing in the PATH environment, programs (externa
On 12/1/2020 4:24 AM, Mattl Mario wrote:
Hello,
Since cygwin1.dll version 3.1.5, I observed the following behavior:
If a symbolic link is existing in the PATH environment, programs (external from
Cygwin's system directory) using cygwin1.dll cannot be executed anymore.
Possibly, because
Hello,
Since cygwin1.dll version 3.1.5, I observed the following behavior:
If a symbolic link is existing in the PATH environment, programs (external from
Cygwin's system directory) using cygwin1.dll cannot be executed anymore.
Possibly, because the Cygwin-DLL isn't found anymore.
Steps
Is it possible to compile only cygwin1.dll in newlib-cygwin
repository? I want to skip building all docs and the installation of
xmlto like programs. Also there is an error:
../../../../winsup/cygwin/gendef: No such file or directory
Any hint?
--
Problem reports: https://cygwin.com
shots/
> > >>>
> > >>> Please give them a try.
> > >> ---
> > >> Got:
> > >>
> > >> "The procedure entry point uname_x could not be located in the dynamic
> > >> link library cygwin1.dll"
> > &g
>> ---
> >> Got:
> >>
> >> "The procedure entry point uname_x could not be located in the dynamic
> >> link library cygwin1.dll"
> >
> > uname_x is exported just fine. You're doing something wrong.
> >
> > Corinna
> ---
On Sep 8 20:47, Thomas Wolff wrote:
>
>
> Am 08.09.2020 um 20:28 schrieb L A Walsh:
> >
> > On 9/8/2020 12:18 AM, Corinna Vinschen wrote:
> > > On Sep 7 14:34, L A Walsh wrote:
> > > > > I uploaded new snapshots for testing to https://cygwin.com/snapshots/
> > > > >
> > > > > Please give
:
"The procedure entry point uname_x could not be located in the dynamic
link library cygwin1.dll"
uname_x is exported just fine. You're doing something wrong.
Corinna
---
I stopped all cygwin processes. Using cmd.exe, I renamed cygwin1.dll
to cygwin1.dll-. I 'copy'd the new dl
uname_x could not be located in the dynamic
>> link library cygwin1.dll"
>
> uname_x is exported just fine. You're doing something wrong.
>
> Corinna
---
I stopped all cygwin processes. Using cmd.exe, I renamed cygwin1.dll
to cygwin1.dll-. I 'copy'd the new dll in place a
On Sep 7 14:34, L A Walsh wrote:
>
> >
> > I uploaded new snapshots for testing to https://cygwin.com/snapshots/
> >
> > Please give them a try.
> ---
> Got:
>
> "The procedure entry point uname_x could not be located in the dynamic
> link lib
>
> I uploaded new snapshots for testing to https://cygwin.com/snapshots/
>
> Please give them a try.
---
Got:
"The procedure entry point uname_x could not be located in the dynamic
link library cygwin1.dll"
:-(
--
Problem reports: https://cygwin
removing files one by one. Eventually I noticed a copy of an old
cygwin1.dll (actually a custom build of 2.10.0) and that of course was
the culprit.
And it makes sense now of course. /usr/bin/as (and cc1) are going to
load cygwin1.dll in /usr/bin, which is consistent with bash/mintty etc,
because
Thank you for the assistance!
I released the latest version of my installer, now available (under
"Releases" tab) here:
https://github.com/Bill-Stewart/Cygwin-OpenSSH
Bill
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
On Thu, 30 Jan 2020 12:33:28 -0700
Bill Stewart wrote:
> On Thu, Jan 30, 2020 at 9:46 AM Takashi Yano wrote:
> > I believe you do not need winpty anymore because newer cygwin
> > utilizes pseudo console in pty.
>
> Since this package is still used for older OS versions, I will still
> need winpty
On Thu, Jan 30, 2020 at 12:33 PM Bill Stewart wrote:
> I added cygwin-console-helper.exe and this resolved it, at least on
> Windows 10. My next step is to test on Server 2012 R2.
Tested, and works fine also on Server 2012 R2. Thanks for the help!
Bill
--
Problem reports:
On Thu, Jan 30, 2020 at 9:46 AM Takashi Yano wrote:
> Bill Stewart wrote:
> >
> > When I use cygwin1.dll versions newer than 3.0.7, sshd.exe hangs
> > whenever establishing a connection.
> > ...
> > Any ideas?
>
> You need cygwin-console-helper.exe for n
ional conveniences (the foremost of which is
> to automatically install the service).
>
> The problem:
>
> When I use cygwin1.dll versions newer than 3.0.7, sshd.exe hangs
> whenever establishing a connection. Following is the output from 'sshd
> -d':
>
> debug1: sshd version Open
:
When I use cygwin1.dll versions newer than 3.0.7, sshd.exe hangs
whenever establishing a connection. Following is the output from 'sshd
-d':
debug1: sshd version OpenSSH_8.1, OpenSSL 1.1.1d 10 Sep 2019
debug1: private host key #0: ssh-rsa SHA256:...
debug1: private host key #1: ecdsa-sha2
On Sat, 4 Jan 2020 10:51:42 +0900
Takashi Yano wrote:
> On Thu, 2 Jan 2020 22:16:02 +
> Ken Brown wrote:
> > I think this narrows it down to one of the following commits:
>
> I looked into this probelm and found the issue occurs after
> the following commit.
>
> > commit
On Thu, 2 Jan 2020 22:16:02 +
Ken Brown wrote:
> I think this narrows it down to one of the following commits:
I looked into this probelm and found the issue occurs after
the following commit.
> commit 915fcd0ae8d83546ce135131cd25bf6795d97966
> Author: Takashi Yano
> Date: Thu Sep 5
[Please don't top-post on this list.]
On 1/2/2020 4:25 PM, ianpu...@gmail.com wrote:
> Now narrowed down to cygwin1.dll version 3.1.0-0.4 as the release which
> introduced this issue.
>
> I found the intervening versions between 3.0.7-1 and 3.1.0-1 as test
> releases in earlier r
Now narrowed down to cygwin1.dll version 3.1.0-0.4 as the release which
introduced this issue.
I found the intervening versions between 3.0.7-1 and 3.1.0-1 as test
releases in earlier release archives at crouchingtigerhiddenfruitbat.org, so
incrementally installing those from 3.1.0-0.1, I found
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=dac0b6826bef8c637866c60d15ffd8461b361f50
commit dac0b6826bef8c637866c60d15ffd8461b361f50
Author: Michael Haubenwallner
Date: Wed Dec 7 11:58:26 2016 +0100
dll_list: Track main executable and cygwin1.dll.
Even
On Jul 6 00:29, Takashi Yano wrote:
> Hi Corinna,
>
> On Wed, 4 Jul 2018 16:52:47 +0200
> Corinna Vinschen wrote:
> > Hang on. /dev/kmsg was implemented using a mailslot and it was never
> > accessible via the syslog(3) interface. The code you removed has
> > nothing to do with /dev/kmsg.
>
>
Hi Brian,
On Thu, 5 Jul 2018 12:38:08 -0600
Brian Inglis wrote:
> Isn't this moot as the supported package is syslog-ng, which seems to work
> okay?
Not only inetutils syslogd but also syslog-ng does not work in cygwin
git HEAD. I confirmed syslog-ng gets back working with the patch I posted.
On 2018-07-05 09:29, Takashi Yano wrote:
> On Wed, 4 Jul 2018 16:52:47 +0200 Corinna Vinschen wrote:
>> Hang on. /dev/kmsg was implemented using a mailslot and it was never
>> accessible via the syslog(3) interface. The code you removed has
>> nothing to do with /dev/kmsg.
>
> First of all,
Hi Corinna,
On Wed, 4 Jul 2018 16:52:47 +0200
Corinna Vinschen wrote:
> Hang on. /dev/kmsg was implemented using a mailslot and it was never
> accessible via the syslog(3) interface. The code you removed has
> nothing to do with /dev/kmsg.
First of all, /dev/kmsg was not guilty. The real
On Jul 4 22:26, Takashi Yano wrote:
> Hi Corinna,
>
> On Wed, 4 Jul 2018 12:54:20 +0200
> Corinna Vinschen wrote:
> > Inetutils is an orphaned package (and rightfully so).
> >
> > If you think you need inetutils and especially syslogd, I suggest
> > to take over maintainance of that package and
On Jul 4 22:01, Takashi Yano wrote:
> Hi Corinna,
>
> On Wed, 4 Jul 2018 12:54:20 +0200
> Corinna Vinschen wrote:
> > On Jul 4 04:44, Takashi Yano wrote:
> > > Why was /dev/kmsg deleted from cygwin1.dll in git?
> > > Due to this change, syslogd
Hi Corinna,
On Wed, 4 Jul 2018 12:54:20 +0200
Corinna Vinschen wrote:
> Inetutils is an orphaned package (and rightfully so).
>
> If you think you need inetutils and especially syslogd, I suggest
> to take over maintainance of that package and tweak syslogd so it
> doesn't require /dev/kmsg
Hi Corinna,
On Wed, 4 Jul 2018 12:54:20 +0200
Corinna Vinschen wrote:
> On Jul 4 04:44, Takashi Yano wrote:
> > Why was /dev/kmsg deleted from cygwin1.dll in git?
> > Due to this change, syslogd in inetutils package no longer works.
>
> /dev/kmsg doesn't really give a
On Wed, 4 Jul 2018 20:49:12 +0900
Takashi Yano wrote:
> Isn't that the mis-operation?
I confirmed that this patch has been applied.
Sorry for impatience.
--
Takashi Yano
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
On Jul 4 20:49, Takashi Yano wrote:
> On Wed, 4 Jul 2018 12:51:08 +0200
> Corinna Vinschen wrote:
> > Thanks for catching. I pushed your patch (using "" rather than <>
> > just for clearness) with a description.
>
> I have pulled the git HEAD just now, but nothing about this.
> Instead, the
On Wed, 4 Jul 2018 12:51:08 +0200
Corinna Vinschen wrote:
> Thanks for catching. I pushed your patch (using "" rather than <>
> just for clearness) with a description.
I have pulled the git HEAD just now, but nothing about this.
Instead, the following patch has been applied.
On Jul 4 04:44, Takashi Yano wrote:
> Why was /dev/kmsg deleted from cygwin1.dll in git?
> Due to this change, syslogd in inetutils package no longer works.
/dev/kmsg doesn't really give any useful information. It was never used
for more than some exception information, but it re
have looked into this problem, and found calling af_local_set_secret()
> in fhandler_socket_local::bind() causes exception 0xc005.
>
> Calling RtlGenRandom() in af_local_set_secret() may not be as expected.
>
> While building cygwin1.dll in 32 bit environment, following w
Why was /dev/kmsg deleted from cygwin1.dll in git?
Due to this change, syslogd in inetutils package no longer works.
--
Takashi Yano
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
secret()
in fhandler_socket_local::bind() causes exception 0xc005.
Calling RtlGenRandom() in af_local_set_secret() may not be as expected.
While building cygwin1.dll in 32 bit environment, following warning is
shown. This is probably the cause.
Warning: resolving _SystemFunction036 by linking to _SystemFunctio
Hi Corinna,
On Tue, 3 Jul 2018 15:05:58 +0200
Corinna Vinschen wrote:
> I just built git HEAD from scratch four times, with and without
> optimization, with and without the preliminary new AF_UNIX code (which
> should be unused running your testcase anyway). WIth each version
> your testcase
1 - 100 of 1459 matches
Mail list logo
