On Thu Apr 10 18:50:59 GMT 2025, ASSI wrote:
> It seems that you are using the test version of Emacs that uses native
> compilation. If so, then please actually read the announcement:
> https://inbox.sourceware.org/cygwin-announce/2e4a21c3-3e94-4771-acf2-7e56e5fce...@cornell.edu/
> If that is
Jim Reisert AD1C via Cygwin writes:
> On one of my computers (but not the other), I get this error when I
> try to start Emacs 29.4 in an xterm:
>
> 0 [main] emacs-gtk 2079 child_info_fork::abort:
> \??\D:\Cygwin\bin\cygpng16-16.dll: Loaded to different address:
> parent(
Greetings, Jim Reisert AD1C!
> On one of my computers (but not the other), I get this error when I
> try to start Emacs 29.4 in an xterm:
> 0 [main] emacs-gtk 2079 child_info_fork::abort:
> \??\D:\Cygwin\bin\cygpng16-16.dll: Loaded to different address:
> parent(0xC
On one of my computers (but not the other), I get this error when I
try to start Emacs 29.4 in an xterm:
0 [main] emacs-gtk 2079 child_info_fork::abort:
\??\D:\Cygwin\bin\cygpng16-16.dll: Loaded to different address:
parent(0xCB) != child(0x25E)
I killed the X server, started a
On Sat, 5 Apr 2025, Jon Turney wrote:
> On 05/04/2025 06:28, Jeremy Drake via Cygwin wrote:
> > I just happened to look at dlfcn.cc dladdr function, and I had a question.
> > Should dladdr be using the GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT
> > flag? It doesn't seem like dladdr should be in
On 05/04/2025 06:28, Jeremy Drake via Cygwin wrote:
I just happened to look at dlfcn.cc dladdr function, and I had a question.
Should dladdr be using the GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT
flag? It doesn't seem like dladdr should be incrementing the refcount.
Indeed. Well spotted.
T
I just happened to look at dlfcn.cc dladdr function, and I had a question.
Should dladdr be using the GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT
flag? It doesn't seem like dladdr should be incrementing the refcount.
--
Problem reports: https://cygwin.com/problems.html
FAQ:
: cygwin@cygwin.com
Cc: Whitney Schmidt ; Sebastian Hernandez
Subject: [Bug check/report] UnDocumented call to
ntdll.dll!NtAssignProcessToJobObject in msys2.0.dll / cygwin - included in
mingit/Git for Windows
Hello Cygwin list,
I’m part of the Visual Studio team at Microsoft which includes mi
e of folks from my team in this email too). One of our
> API scanning tools has identified msys2.0.dll calling undocumented
> Windows APIs like ntdll.dll!NtAssignProcessToJobObject:
>
> * In cygwin -
>
> https://github.com/search?q=repo%3Acygwin%2Fcygwin+NtAssignPr
Hello Cygwin list,
I'm part of the Visual Studio team at Microsoft which includes mingit/Git for
Windows in our product for Git tooling integration (I'm copying a couple of
folks from my team in this email too). One of our API scanning tools has
identified msys2.0.dll calling un
On Tue, 05 Mar 2024 20:48:38 +0900 (JST)
Masamichi Hosoda wrote:
> libfontconfig-devel-2.15.0-1 links wrong DLL (i.e. libfontconfig-1.dll)
Thanks for the report. I'll fix that and release version 2.15.0-2.
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.
Hi
If I understand correctly,
libfontconfig-devel-2.15.0-1 links wrong DLL (i.e. libfontconfig-1.dll)
instead of correct DLL (i.e. cygfontconfig-1.dll).
Since the wrong DLL does not exist,
the executable file using libfontconfig-devel-2.15.0-1 cannot be executed.
```
$ cat foo.c
#include
int
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 06/02/2024 23:10, Kaz Kylheku via Cygwin wrote:
On 2024-02-04 21:22, Suman Chakraborty via Cygwin wrote:
1. Executive Summary:
The vulnerability pertains to not finding
the profapi.dll, CFGMGR32.dll, edputil.dll, urlmon.dll, SspiCli.dll,
Wldp.dll, MPR.dll, ServicingCommon.dll
On 2024-02-06 15:10, Kaz Kylheku via Cygwin wrote:
On 2024-02-04 21:22, Suman Chakraborty via Cygwin wrote:
1. Executive Summary:
The vulnerability pertains to not finding
the profapi.dll, CFGMGR32.dll, edputil.dll, urlmon.dll, SspiCli.dll,
Wldp.dll, MPR.dll, ServicingCommon.dll
On 2024-02-04 21:22, Suman Chakraborty via Cygwin wrote:
> 1. Executive Summary:
>
> The vulnerability pertains to not finding
> the profapi.dll, CFGMGR32.dll, edputil.dll, urlmon.dll, SspiCli.dll,
> Wldp.dll, MPR.dll, ServicingCommon.dll, TextShaping.dll, CRYPTBASE.DLL,
&g
tps://cygwin.com/setup-x86_64.exe> that I believe warrants your
immediate attention.
1. Executive Summary:
The vulnerability pertains to not finding
the profapi.dll, CFGMGR32.dll, edputil.dll, urlmon.dll, SspiCli.dll,
Wldp.dll, MPR.dll, ServicingCommon.dll, TextShaping.dll, CRYPTBASE.DLL,
PROPSYS.d
ker to execute arbitrary
code on a victim's machine, potentially leading to data breaches, system
compromise, and other malicious activities.
2. Details of the Vulnerability:
Type: DLL Hijacking
Affected Component: profapi.dll
Impact: Remote Code Execution, Data Theft or
Manipulation,
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-
Greetings, Bruce Visscher!
> As a matter of fact, perhaps I don't need winpty anymore. I used to
> have to prefix some windows console apps with this but that doesn't
> seem to be necessary now.
There have been some progress on Microsoft side regarding console behavior in
general, yes.
But in g
ker to execute arbitrary
code on a victim's machine, potentially leading to data breaches, system
compromise, and other malicious activities.
2. Details of the Vulnerability:
Type: DLL Hijacking
Affected Component: profapi.dll
Impact: Remote Code Execution, Data Theft or
Manipulation,
ker to execute arbitrary
code on a victim's machine, potentially leading to data breaches, system
compromise, and other malicious activities.
2. Details of the Vulnerability:
Type: DLL Hijacking
Affected Component: profapi.dll
Impact: Remote Code Execution, Data Theft or
Manipulation,
Mümin A. via Cygwin wrote:
Hi,
reminder..
Mümin A. , 11 Tem 2023 Sal, 09:47 tarihinde şunu
yazdı:
Hi,
I'm facing a problem while linking my native dll library into the g++
compiler.
There is a name mangling problem when calling a msvc function from g++
compiler therefore linker giv
Hi,
reminder..
Mümin A. , 11 Tem 2023 Sal, 09:47 tarihinde şunu
yazdı:
>
> Hi,
>
> I'm facing a problem while linking my native dll library into the g++
> compiler.
>
> There is a name mangling problem when calling a msvc function from g++
> compiler therefore li
On 11/07/2023 08:47, Mümin A. via Cygwin wrote:
Hi,
I'm facing a problem while linking my native dll library into the g++
compiler.
There is a name mangling problem when calling a msvc function from g++
compiler therefore linker gives an error undefined reference.
Is there any meth
Hi,
I'm facing a problem while linking my native dll library into the g++
compiler.
There is a name mangling problem when calling a msvc function from g++
compiler therefore linker gives an error undefined reference.
Is there any method to directly link and call a function from nativ
Forwarded this response, since I messed up the reply-to:
On 22/05/2023 02:35, Rodney Brown wrote:
My Cygwin installation has been upgraded over the years, so could have
problematic remnants.
I note the corporate C:\Program Files\McAfee\DLP\Agent\fcagpph64.dll in the mix
& don’t unders
Brian,
On Wed, May 17, 2023 at 7:23 PM Brian Inglis wrote:
> You are definitely missing and need to install libffi8 and libgc1.
Thanks. After installing these via cygwin setup, make is working well.
In fact, the installation also corrected an issue I was having with
python. Previously,
> whi
$ uname -a
CYGWIN_NT-10.0-19045 X 3.4.6-1.x86_64 2023-02-14 13:23 UTC x86_64 Cygwin
$ ldd --version
ldd (cygwin) 3.4.6
As with "ldd freezes"
https://sourceware.org/legacy-ml/cygwin/2015-07/msg00314.html , cygcheck works,
not only for Cygwin DLLs and ldd hangs needing the xterm to be closed, thoug
I get:
$ make
C:/cygwin64/bin/make.exe: error while loading shared libraries: ?: cannot open
shared object file: No such file or directory
$ cygcheck make
Found: C:\cygwin64\bin\make.exe
C:\cygwin64\bin\make.exe
C:\cygwin64\bin\cygwin1.dll
C:\Windows\system32\KERNEL32.dll
C:\Wi
in from PATH.
Now, I get:
> $ make
> C:/cygwin64/bin/make.exe: error while loading shared libraries: ?: cannot
> open shared object file: No such file or directory
>
> $ cygcheck make
> Found: C:\cygwin64\bin\make.exe
> C:\cygwin64\bin\make.exe
> C:\cygwin64\bin\cygw
uname -a
CYGWIN_NT-10.0-22621 42MF1T3 3.4.6-1.x86_64 2023-02-14 13:23 UTC x86_64 Cygwin
$ make
C:/cygwin64/bin/make.exe: error while loading shared libraries:
cygguile-3.0-1.dll: cannot open shared object file: No such file or directory
$ cygcheck make
Found: C:\cygwin64\bin\make.exe
C:\cygwin64\
error while loading shared libraries:
> cygguile-3.0-1.dll: cannot open shared object file: No such file or directory
> $ cygcheck make
> Found: C:\cygwin64\bin\make.exe
> C:\cygwin64\bin\make.exe
> C:\cygwin64\bin\cygwin1.dll
> C:\Windows\system32\KERNEL32.dll
>
> 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
On 17/12/2022 23:15, Brian Inglis via Cygwin wrote:
Just upgraded all packages including Cygwin last night and get occasional:
[...]
Noticed current release is much smaller than previous and my local DLL:
$ TZ=UTC ls -glort /bin/cygwin1*.dll
-rwxr-xr-x 1 3588124 Sep 5 11:17 /bin/cygwin1
libraries: ?: cannot open shared object file: No such file or
> > directory
> >
> > $ cygcheck.exe
> > /cygdrive/c/cygwin64/usr/libexec/git-core/git-remote-https.exe
[...]
> > cygcheck: track_down: could not find cyggsasl-18.dll
> >
> > 8<---
te-https.exe
> c:\cygwin64\usr\libexec\git-core\git-remote-https.exe
> C:\cygwin64\bin\cygcurl-4.dll
> C:\cygwin64\bin\cygbrotlidec-1.dll
> C:\cygwin64\bin\cygwin1.dll
> C:\Windows\system32\KERNEL32.dll
> C:\Windows\system32\ntdll.dll
>
loading
shared libraries: ?: cannot open shared object file: No such file or directory
$ cygcheck.exe /cygdrive/c/cygwin64/usr/libexec/git-core/git-remote-https.exe
c:\cygwin64\usr\libexec\git-core\git-remote-https.exe
C:\cygwin64\bin\cygcurl-4.dll
C:\cygwin64\bin\cygbrotlidec-1.dll
C
> "ssh-pageant.sh" -k
> gpgconf --kill gpg-agent dirmngr scdaemon
> sh -c "for svc in $( cygrunsrv --list | grep -v cygserver ) cygserver; do net
> stop "^"$svc^""; done"
>
> Restarting after setup is goin gthe other way around, except GPG services
> (they are restarted by themselves as needed).
>
Greetings, Keith Christian!
> Hi Ken,
> Yes, I attempt to shut down all cygwin processes as we all have done
> over the past many years of enjoying Cygwin.
> I opened a terminal as Administrator to shut down cygsshd and exim as
> shown below but it did not work.
> What could be wrong here? I am
On 31/07/2022 17:53, Keith Christian wrote:
Hi Jon,
What did I just ask you not to do? And then you go and do it!
Sigh.
Ok, may I know what the procedure is to suggest enhancements?
Please explain what makes you think that it's going to be something
other than "send an email to the list"
Hi Ken,
Yes, I attempt to shut down all cygwin processes as we all have done
over the past many years of enjoying Cygwin.
I opened a terminal as Administrator to shut down cygsshd and exim as
shown below but it did not work.
What could be wrong here? I am surprised that cygrunsrv was unable to
st
On 7/31/2022 7:36 AM, Keith Christian wrote:
On two different Windows 10 machines, I see the Retry/Continue dialog
on numerous cygwin .dll files.
These are the only cygwin processes extant while setup is running:
[...]
Setup might benefit from the "Continue" option having a c
On 31/07/2022 12:36, Keith Christian wrote:
(I'll send these ideas to the setup maintainer in a separate email.)
Please don't.
(I don't want to give anyone the idea that is an acceptable thing to do.)
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygw
On two different Windows 10 machines, I see the Retry/Continue dialog
on numerous cygwin .dll files.
These are the only cygwin processes extant while setup is running:
==
C:\Users\keith>tasklist /v | findstr /c:ssh
sshd.
Hi Ken and Brian-
Please see the make report below.
How do I direct php_amf3 to see cygphp7-7-3.dll? It will only give me a 'static
module'. I need dynamic!
Also, my bitdefender slows down cygwin. If I shut off the shield, it runs like
a champ. I am going to re run again and see if
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
Thanks Ken and Brian,Roboloki
Sent from Yahoo Mail on Android
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
On 5/26/2022 12:23 PM, Jim McNamara via Cygwin wrote:
there is only libphp7.dll.a
That's what you need for linking. The corresponding DLL is
/usr/bin/cygphp7-7-3.dll, which is in the php package.
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ:
only dynamic libraries, and php installs
/usr/bin/cygphp7-7-3.dll, which cygwin libtool should find and use.
You should also check the options available from configure e.g.
--disable-static and --disable-rpath as rpath is not normally used in
Cygwin builds IIRC.
--
Take care. Thanks, Brian I
there is only libphp7.dll.a
thanks again,
ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
thanks
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
On 5/26/2022 11:57 AM, Jim McNamara via Cygwin wrote:
hi all-
I have tracked down the problem and wondering if you had a suggestion to help
me fix it. Is there any reason why the package on the mirror doesn't have
library -lphp7? Is there a way I can get one or do something to solve this
prob
hi all-
I have tracked down the problem and wondering if you had a suggestion to help
me fix it. Is there any reason why the package on the mirror doesn't have
library -lphp7? Is there a way I can get one or do something to solve this
problem? I tried 2 different PhP package versions on the mir
ata = 'C:\Windows\System32\Drivers\DriverData'
SESSIONNAME = 'Console'
MACRIUM_1784_BACKUP_TYPE = '0'
ProgramFiles(x86) = 'C:\Program Files (x86)'
MACRIUM_1785_FILECOUNT = '8'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ &#
On 11/28/2021 3:50 PM, Verachten Bruno via Cygwin wrote:
Hello there,
I installed Remmina tonight, and got this error when launching it:
"error while loading shared libraries: cygssh_threads-4.dll: cannot
open shared object file: No such file or directory
That DLL used to be provided b
1 - 100 of 3913 matches
Mail list logo
