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'
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 mak
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 mak
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
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 solving
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
"initialize
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:
> > >
> > >st
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;
> >
> > th
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 = PTHREAD_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(&m);
> pthread_mutex_unlo
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, th
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 cancell
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 b/winsup/cygwin/thread
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
> --- a/winsup/cygwin/thread.
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 mac
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.
https://www.ibm.com/docs/en/aix/7.3?topic=p-pthrea
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:
h
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
> > __gthread
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
> __gthre
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 handle l
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 into this
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 IT
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 documented.
T
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 (vi
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 i
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 mig
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 situat
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'
stribution 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 mor
t; However, 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
> &
, 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.
> All the required libraries could be found using DependencyWalker and cygcheck.
> Of course, as
ether 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 b
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 correct tha
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/
Documenta
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
Commer
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
> > > > > (external
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 behavior:
>
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, becaus
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.
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 them
:
"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
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
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
part) issue with Windows, I
started 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 consiste
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: http://cygwin.co
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
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 ve
:
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:
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 915fcd0ae8d83546ce135
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 13:22:
[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 earl
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
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
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 anymo
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 foll
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.
https://cygwin.com/ml
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
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
t()
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 prin
On Jul 3 19:44, Takashi Yano wrote:
> Named AF_UNIX socket does not work in cygwin1.dll of git HEAD.
>
> A simple test case is attched.
>
> Expected result:
> 10: 1234567890
>
> Result in cygwin1.dll of git HEAD:
> bind: Bad address
> unlink: Device or resource bu
Named AF_UNIX socket does not work in cygwin1.dll of git HEAD.
A simple test case is attched.
Expected result:
10: 1234567890
Result in cygwin1.dll of git HEAD:
bind: Bad address
unlink: Device or resource busy
It seems that this occures regarding the following commit.
commit
Am 25.06.2018 um 13:20 schrieb Takashi Yano:
Hi Corinna,
On Mon, 25 Jun 2018 11:14:32 +0200
Corinna Vinschen wrote:
Takashi, does your patch on cygwin-patches take this into account?
I think Thomas has a good point here, the generated files should
always match a single version.
I submitted a
Hi Corinna,
On Mon, 25 Jun 2018 11:14:32 +0200
Corinna Vinschen wrote:
> Takashi, does your patch on cygwin-patches take this into account?
>
> I think Thomas has a good point here, the generated files should
> always match a single version.
I submitted a new patch taking that point into account
Hi Thomas,
On Sun, 24 Jun 2018 18:34:06 +0200
Thomas Wolff wrote:
> I would have chosen other markers than 0/1 for the two cases (maybe
> "firstlast" for the new one), and not put it in the middle, but you
> fixed it anyway; except for the Private Use ranges E000..F8FF,
> F..D, 10..
On Jun 24 18:34, Thomas Wolff wrote:
> Am 24.06.2018 um 00:32 schrieb Thomas Wolff:
> > Am 23.06.2018 um 20:46 schrieb Brian Inglis:
> > > On 2018-06-22 17:06, Takashi Yano wrote:
> > > > On Sat, 23 Jun 2018 05:39:27 +0900
> > > > Takashi Yano wrote:
> > > > > I looked into this problem, and found
Am 24.06.2018 um 00:32 schrieb Thomas Wolff:
Am 23.06.2018 um 20:46 schrieb Brian Inglis:
On 2018-06-22 17:06, Takashi Yano wrote:
On Sat, 23 Jun 2018 05:39:27 +0900
Takashi Yano wrote:
I looked into this problem, and found this is caused by incorrect
return value of iswprint().
I have found
On 2018-06-24 06:27, Steven Penny wrote:
> On Sun, 24 Jun 2018 00:32:59, Thomas Wolff wrote:
>> Why not awk? Because I am not familiar with awk.
Suggestion was awk having suitable capabilities, but perl, python, ruby, or any
other would do.
> Should be a simple script, something like this:
> $ aw
On Sun, 24 Jun 2018 00:32:59, Thomas Wolff wrote:
Why not awk? Because I am not familiar with awk.
Should be a simple script, something like this:
$ awk -F ';' '{printf "{CAT_%s, 0x%s, %d},\n", $3, $1, $4}' UnicodeData.txt
{CAT_Lo, 0x3400, 0},
{CAT_Lo, 0x4DB5, 0},
{CAT_Lo, 0x4E00, 0},
{CAT_Lo,
1 - 100 of 1417 matches
Mail list logo
