python build issue

Hi guys, I'm trying to run a python script that requires yfinance.  This is the error I'm getting: $ pip3 install yfinance Collecting yfinance   Using cached yfinance-0.2.63-py2.py3-none-any.whl.metadata (5.8 kB) Collecting pandas>=1.3.0 (from yfinance)   Using cached pandas-2.3.0.tar.gz (4.

Re: openssl and libcurl issue with cargo

On Tue, 3 Jun 2025, Jeremy Drake via Cygwin wrote: > On Sun, 1 Jun 2025, Jon Turney wrote: > > > On 25/05/2025 17:53, Jeremy Drake via Cygwin wrote: > > > On Sun, 25 May 2025, ASSI via Cygwin wrote: > > > > > > > Jeremy Drake via Cygwin writes: > > > > > Apparently the fix that MSYS2 made for open

Re: openssl and libcurl issue with cargo

On Sun, 1 Jun 2025, Jon Turney wrote: > On 25/05/2025 17:53, Jeremy Drake via Cygwin wrote: > > On Sun, 25 May 2025, ASSI via Cygwin wrote: > > > > > Jeremy Drake via Cygwin writes: > > > > Apparently the fix that MSYS2 made for openssl in > > > > https://github.com/msys2/MSYS2-packages/pull/3448

Re: openssl and libcurl issue with cargo

On 25/05/2025 17:53, Jeremy Drake via Cygwin wrote: On Sun, 25 May 2025, ASSI via Cygwin wrote: Jeremy Drake via Cygwin writes: Apparently the fix that MSYS2 made for openssl in https://github.com/msys2/MSYS2-packages/pull/3448 is also not present in Cygwin, so cargo continues to crash after

Re: openssl and libcurl issue with cargo

On 2025-05-25 13:03, Brian Inglis wrote: On 2025-05-25 12:30, Jeremy Drake wrote: On Sun, 25 May 2025, Brian Inglis via Cygwin wrote: So please try installing the relevant Cygwin/Mingw64 OpenSSL test packages, with the latest curl packages, retest and report, if you don't mind. Cargo

Re: openssl and libcurl issue with cargo

On Sun, 25 May 2025, Brian Inglis via Cygwin wrote: > On 2025-05-25 12:30, Jeremy Drake wrote: > > Cargo issue (manifests as a hang, but running under gdb shows a SIGSEGV) > > still reproduces without the curl patch :( > > Could you please post the gdb backtrace and build

Re: openssl and libcurl issue with cargo

On 2025-05-25 12:30, Jeremy Drake wrote: On Sun, 25 May 2025, Brian Inglis via Cygwin wrote: So please try installing the relevant Cygwin/Mingw64 OpenSSL test packages, with the latest curl packages, retest and report, if you don't mind. Cargo issue (manifests as a hang, but running

Re: openssl and libcurl issue with cargo

On Sun, 25 May 2025, Brian Inglis via Cygwin wrote: > So please try installing the relevant Cygwin/Mingw64 OpenSSL test packages, > with > the latest curl packages, retest and report, if you don't mind. Cargo issue (manifests as a hang, but running under gdb shows a SIGSEGV) st

Re: openssl and libcurl issue with cargo

On Sun, 25 May 2025, Brian Inglis via Cygwin wrote: > So please try installing the relevant Cygwin/Mingw64 OpenSSL test packages, > with > the latest curl packages, retest and report, if you don't mind. > I've got 'dist' tarballs built for Cygwin, in https://github.com/jeremyd2019/rust/releases/t

Re: openssl and libcurl issue with cargo

On Sun, 25 May 2025, ASSI via Cygwin wrote: > Jeremy Drake via Cygwin writes: > > Apparently the fix that MSYS2 made for openssl in > > https://github.com/msys2/MSYS2-packages/pull/3448 is also not present in > > Cygwin, so cargo continues to crash after I patched libcurl. > > I have the opposite

Re: openssl and libcurl issue with cargo

-svc AsynchDNS brotli gsasl GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd So the issue still exists in Cygwin OpenSSL LTS 3.0.16-1 and ASSI/Stromeko has patched it in Cygwin OpenSSL 3.0.16-2 and mingw64-x86_64/i686-ope

Re: openssl and libcurl issue with cargo

TTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd So the issue still exists in Cygwin OpenSSL LTS 3.0.16-1 and ASSI/Stromeko has patched it in Cygwin OpenSSL 3.0.16-2 and mingw64-x86_64/i686-openssl 3.0.16-2 test package rele

Re: openssl and libcurl issue with cargo

Jeremy Drake via Cygwin writes: > Apparently the fix that MSYS2 made for openssl in > https://github.com/msys2/MSYS2-packages/pull/3448 is also not present in > Cygwin, so cargo continues to crash after I patched libcurl. I have the opposite view on crashing vs. leaking memory from openSSL, but t

Re: openssl and libcurl issue with cargo

On Sat, 24 May 2025, Jeremy Drake via Cygwin wrote: > I'm trying to get rust and cargo working on Cygwin (as github user > @Berrysoft is getting it going on MSYS2), and I wanted to direct the curl > maintainer's attention to https://github.com/curl/curl/issues/17262. I am > hitting this now with

libcurl issue with cargo

I'm trying to get rust and cargo working on Cygwin (as github user @Berrysoft is getting it going on MSYS2), and I wanted to direct the curl maintainer's attention to https://github.com/curl/curl/issues/17262. I am hitting this now with cargo on Cygwin with curl 8.13.0-1. There was a workaround a

Re: Cygwin 3.6: clang cannot use /usr/include/unistd.h, issue with |setproctitle_init()| ...

Guys, I already applied a patch. Thanks, Corinna On Mar 5 15:51, Glenn Strauss via Cygwin wrote: > On Wed, Mar 05, 2025 at 08:27:53PM +, Lavrentiev, Anton (NIH/NLM/NCBI) > [C] via Cygwin wrote: > > > We could change this to a macro instead: > > > > > > -static inline void setproctitle_init

Re: Cygwin 3.6: clang cannot use /usr/include/unistd.h, issue with |setproctitle_init()| ...

On Wed, Mar 05, 2025 at 08:27:53PM +, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > We could change this to a macro instead: > > > > -static inline void setproctitle_init (int, char *[], char *[]) {} > > +#define setproctitle_init(c, a, e) > > Changing to the empty marco removes

RE: [EXTERNAL] Re: Cygwin 3.6: clang cannot use /usr/include/unistd.h, issue with |setproctitle_init()| ...

> We could change this to a macro instead: > > -static inline void setproctitle_init (int, char *[], char *[]) {} > +#define setproctitle_init(c, a, e) Changing to the empty marco removes the side effects in the arguments (such as len++, for example), which may silently break existing code -- so

Re: Cygwin 3.6: clang cannot use /usr/include/unistd.h, issue with |setproctitle_init()| ...

On Mar 5 20:10, Dimitry Andric via Cygwin wrote: > Maybe it's because -Wsystem-headers is not enabled? I'm unsure what > gcc's default behavior is with -Wall, but if you add an explicit > -Wsystem-headers you might still get that warning. Thanks, that was the reason. With -Wsystem-headers I can r

Re: Cygwin 3.6: clang cannot use /usr/include/unistd.h, issue with |setproctitle_init()| ...

On Mar 5 17:16, Christian Franke via Cygwin wrote: >> Roland Mainz via Cygwin wrote: >>> Small issue with Cygwin 3.6 (3.6.0-0.419.g3c1308ed890e.x86_64) system >>> /usr/include/unistd.h and clang: >>> snip >>> $ clang --version >>> clang ve

RE: [EXTERNAL] Re: Cygwin 3.6: clang cannot use /usr/include/unistd.h, issue with |setproctitle_init()| ...

> The error is valid because the addition of this very old C++ feature > took a very long time :-) Well, it may be so, but adding the parameter names in those prototype on Cygwin end of things would be a better and less disruptive approach, IMO. $.02, Anton Lavrentiev Contractor NIH/NLM/NCBI -

Re: Cygwin 3.6: clang cannot use /usr/include/unistd.h, issue with |setproctitle_init()| ...

On Mar 5 17:16, Christian Franke via Cygwin wrote: > Roland Mainz via Cygwin wrote: > > Small issue with Cygwin 3.6 (3.6.0-0.419.g3c1308ed890e.x86_64) system > > /usr/include/unistd.h and clang: > > snip > > $ clang --version > > clang version 8.0.1 (t

Re: Cygwin 3.6: clang cannot use /usr/include/unistd.h, issue with |setproctitle_init()| ...

Roland Mainz via Cygwin wrote: Small issue with Cygwin 3.6 (3.6.0-0.419.g3c1308ed890e.x86_64) system /usr/include/unistd.h and clang: snip $ clang --version clang version 8.0.1 (tags/RELEASE_801/final) Target: x86_64-unknown-windows-cygnus Thread model: posix InstalledDir: /usr/bin

Cygwin 3.6: clang cannot use /usr/include/unistd.h, issue with |setproctitle_init()| ...

Hi! Small issue with Cygwin 3.6 (3.6.0-0.419.g3c1308ed890e.x86_64) system /usr/include/unistd.h and clang: snip $ clang --version clang version 8.0.1 (tags/RELEASE_801/final) Target: x86_64-unknown-windows-cygnus Thread model: posix InstalledDir: /usr/bin $ clang -std=gnu17 -Wall

Re: Potential Argument Injection Issue in Cygwin's Command Line Handling

On 2025-02-10 19:09, Kaz Kylheku wrote: On 2025-02-10 12:32, Brian Inglis via Cygwin wrote: One can avoid any issues by running Cygwin programs only from other Cygwin programs, and Windows programs only from other Windows programs. Microsoft has provided a documented algorithm, which is imple

Re: Potential Argument Injection Issue in Cygwin's Command Line Handling

egins with wmain. I don't want Cygnal programs to be susceptible to the alleged argument injection when invoked by non-Cygwin applications that are following the Microsoft-recommended command line convention. Therefore, if you produce a good patch for this issue, I will likely merge it in the Cyg

Re: Potential Argument Injection Issue in Cygwin's Command Line Handling

On 2025-02-10 12:32, Brian Inglis via Cygwin wrote: > One can avoid any issues by running Cygwin programs only from other Cygwin > programs, and Windows programs only from other Windows programs. Microsoft has provided a documented algorithm, which is implemented in the ShellAPI function Command

Re: Potential Argument Injection Issue in Cygwin's Command Line Handling

idden-transformers-in-windows-ansi/ Yes, I agree with you, this design has always been really problematic, that was totally a bad idea. But at this point, it's probably a huge design debt, and I imagine it’s not an easy fix for Microsoft. Back to this issue, the argument parsing logic is indeed

Re: Potential Argument Injection Issue in Cygwin's Command Line Handling

formers-in-windows-ansi/ Yes, I agree with you, this design has always been really problematic, that was totally a bad idea. But at this point, it's probably a huge design debt, and I imagine it’s not an easy fix for Microsoft. Back to this issue, the argument parsing logic is indeed handled b

Re: Potential Argument Injection Issue in Cygwin's Command Line Handling

t;', ' a b c'], returncode=0) > > > > it seems correct to me for a Cygwin Python > > This behavior appears correct for Cygwin Python because it assumes it > is running on a POSIX system. As a result, it uses Cygwin's simulated > `execve` system call rather than

Re: Potential Argument Injection Issue in Cygwin's Command Line Handling

r Cygwin Python because it assumes it is running on a POSIX system. As a result, it uses Cygwin's simulated `execve` system call rather than Windows' command-line parsing mechanism and the parsing mechanism within Cygwin itself is consistent so everything goes fine here. To be more specif

Re: Potential Argument Injection Issue in Cygwin's Command Line Handling

On 04/02/2025 07:15, Splitline Huang via Cygwin wrote: Hello Cygwin team, I am splitline from DEVCORE research team. I recently have observed an inconsistency in how Cygwin handles command-line parsing compared to Microsoft’s implementation. According to Microsoft’s documentation [1], the \" s

Potential Argument Injection Issue in Cygwin's Command Line Handling

Hello Cygwin team, I am splitline from DEVCORE research team. I recently have observed an inconsistency in how Cygwin handles command-line parsing compared to Microsoft’s implementation. According to Microsoft’s documentation [1], the \" sequence should always be interpreted as a literal double

Re: Cygwin 3.6 possible issue handling compressed .pdb files on SSD?

se there are no holes in that file. That itself is IMHO already a bad idea to have a separate codepath for sparse files, just the normal codepath should use SEEK_HOLE and just skip those in the destination A possible issue is that Cygwin assumes sparse files on SSD No, that's not the probl

Re: Cygwin 3.6 possible issue handling compressed .pdb files on SSD?

nk the issues here are: > > 1. Coreutils 9.5-1 /bin/cp erroneously assumes that a file is sparse > > if the number of blocks is smaller than $((filesize / fs_blocksize)) - > > but in this case the file is NOT sparse, just compressed. > > 2. The loop to copy a sparse file i

Re: Cygwin 3.6 possible issue handling compressed .pdb files on SSD?

e a separate codepath for sparse files, just the normal codepath should use SEEK_HOLE and just skip those in the destination A possible issue is that Cygwin assumes sparse files on SSD, so we need fhandler/disk_file:fstat_helper to allow cp to handle compressed files normally. -- Take care. Th

Re: ImageJ Java Windows issue

On 2024-12-31 10:43, Fiducia, Tom Arthur Michael via Cygwin wrote: Hi, I'm trying to import a .cr3 file into imagej using the DCRaw reader. It is giving the error listed below. Do you know what I can do to fix this? Cannot decode file C:\Users\fiduc\OneDrive\Data\NadeeshaNew\NadeeshaXmas_awake_

Re: cpu issue on when using less

cygwin 3.6.0-0.280.g2a1f407b0919 On Thu, Dec 12, 2024 at 11:53 AM Takashi Yano wrote: > On Thu, 12 Dec 2024 11:24:40 +0800 > 凯夏 via Cygwin wrote: > > When I use less read from pipe,even i just output a empty new line to > less, > > the bash running less gets high cpu usage ( picture 1, picture

Re: cpu issue on when using less

On Thu, 12 Dec 2024 11:24:40 +0800 凯夏 via Cygwin wrote: > When I use less read from pipe,even i just output a empty new line to less, > the bash running less gets high cpu usage ( picture 1, picture 2 ), and > less itself didn't use many cpu, when i quit less, cpu usage of bash drop > to normal (

cpu issue on when using less

When I use less read from pipe,even i just output a empty new line to less, the bash running less gets high cpu usage ( picture 1, picture 2 ), and less itself didn't use many cpu, when i quit less, cpu usage of bash drop to normal ( picture 3 ) When I use less read from file,the bash running less

Re: Thread memory allocation issue

Hi Teemu, On 11/18/2024 10:59 PM, Teepean via Cygwin wrote: 2. Compile BWA with rpmalloc and the following patch: // In thread worker function: #ifdef __CYGWIN__ rpmalloc_thread_initialize(); #endif // ... thread work ... #ifdef __CYGWIN__ rpmalloc_thread_finalize(1); #endif How, exactly,

Re: Possible issue with check_dir_not_empty

ed as iterator. > > > Therefore it holds no longer the initial buffer at the call > > > to NtQueryDirectoryFile in the while conditition at the bottom. > > > > Good catch, thank you! > > Forgot to mention the background. I actually hit this issue with running > Cygwin'

Re: Thread memory allocation issue

ree hours would take 24 hours or more on an unpatched bwa on Cygwin. >> 1. The default malloc implementation shows extremely high system time >> (11.265s) compared to the rpmalloc version (0.327s) >> 2. Total real time is about 4.5x slower with default malloc >> 3

Re: Thread memory allocation issue

Hello Teepean, On 11/17/2024 11:32 AM, Teepean via Cygwin wrote: I raised this issue couple of years ago on cygwin-developer but now when the problem has manifested again with recent versions of Cygwin I decided to post this to general discussion list. This (main Cygwin) list is the correct

Re: Possible issue with check_dir_not_empty

NtQueryDirectoryFile call before the loops. In the loop the pointer pfni is also used as iterator. Therefore it holds no longer the initial buffer at the call to NtQueryDirectoryFile in the while conditition at the bottom. Good catch, thank you! Forgot to mention the background. I actually hit this issue

Re: Possible issue with check_dir_not_empty

Hi Bernhard, On Nov 16 23:36, Bernhard Übelacker via Cygwin wrote: > Hello everyone, > > Is is about the buffer allocated in check_dir_not_empty. > > The pointer pfni gets allocated the buffer at the begin, > and is used in the NtQueryDirectoryFile call before the loops. > In the loop the pointe

Thread memory allocation issue

Hello! I raised this issue couple of years ago on cygwin-developer but now when the problem has manifested again with recent versions of Cygwin I decided to post this to general discussion list. Steps to Reproduce 1. Compile BWA normally https://github.com/lh3/bwa/ 2. Compile BWA with

Possible issue with check_dir_not_empty

Hello everyone, Is is about the buffer allocated in check_dir_not_empty. The pointer pfni gets allocated the buffer at the begin, and is used in the NtQueryDirectoryFile call before the loops. In the loop the pointer pfni is also used as iterator. Therefore it holds no longer the initial buffer

Re: double-fork issue on Windows on ARM64

Replying to cygwin@cygwin.com list due to determination that this thread was incorrectly sent to cygwin-developers. I apologize for the inconvenience. On Tue, 21 May 2024, Jeremy Drake wrote: > On Mon, 20 May 2024, Jeremy Drake wrote: > > > Today, I was attempting to look at the TerminateThread

Re: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"

christianon39--- via Cygwin writes: > /usr/include/sys/signalfd.h:17:17: error: 'O_CLOEXEC' undeclared here (not in > a function); did you mean 'FD_CLOEXEC'? >17 | SFD_CLOEXEC = O_CLOEXEC, > |  ^ > |  FD_CLOEXEC > --

Re: Sv: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"

On 18/06/2024 23:15, christianon39--- via Cygwin wrote: This is a test file I ran so that I didnt need to run the build every time for wlroots. Compiled to exe file with "gcc -o checko test.c". Needs to have a file just called testfile to work Uh, is the claim that this file also produces the sam

Sv: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"

17:07 Til: cygwin@cygwin.com Emne: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?" Hi, I am trying to build wlroots, but get this error in meson logs: Command line: `cc /home/Chris/wlroots/build/m

Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"

Hi, I am trying to build wlroots, but get this error in meson logs: Command line: `cc /home/Chris/wlroots/build/meson-private/tmprxphcsub/testfile.c -o /home/Chris/wlroots/build/meson-private/tmprxphcsub/output.obj -c -D_FILE_OFFSET_BITS=64 -O0 -std=c11` -> 1 stderr: In file included from /home

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

On Sun, 02 Jun 2024 15:14:51 +0200 Bruno Haible wrote: > Hi Takashi Yano, > > > The result is as follows (submitted as v4 patch). > > > > int > > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > > { > > /* Sign bit of once_control->state is used as done flag. > >

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Hi Takashi Yano, > The result is as follows (submitted as v4 patch). > > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > /* Sign bit of once_control->state is used as done flag. > Similary, the next significant bit is used as destroyed flag. */ > con

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

On Sat, 1 Jun 2024 12:08:51 -0400 Ken Brown wrote: > Hi Takashi, > > On 6/1/2024 10:18 AM, Takashi Yano via Cygwin wrote: > > int > > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > > { > >/* Sign bit of once_control->state is used as done flag. > > Similary,

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Hi Takashi, On 6/1/2024 10:18 AM, Takashi Yano via Cygwin wrote: int pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) { /* Sign bit of once_control->state is used as done flag. Similary, the next significant bit is used as destroyed flag. */ Typo: Simi

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Hi Bruno, On Fri, 31 May 2024 16:01:35 +0200 Bruno Haible wrote: > Hi Takashi Yano, > > > With v3 patch: > > int > > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > > { > > /* Sign bit of once_control->state is used as done flag */ > > if (once_control->state & INT

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Hi Takashi Yano, > With v3 patch: > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > /* Sign bit of once_control->state is used as done flag */ > if (once_control->state & INT_MIN) > return 0; > // HERE: Point A. > /* The type of &once_control->

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches: > With v3 patch: > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > /* Sign bit of once_control->state is used as done flag */ > if (once_control->state & INT_MIN) > return 0; > > /* The type of &once_control->sta

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

On 5/30/2024 11:15 AM, Bruno Haible wrote: Still: Does ReleaseSRWLockExclusive notify other threads? Of course? How else would a lock work, it must release other waiters? It might not be a fair lock though, which is not a problem for this situation, which does not require fair locking.

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches: > int > pthread::once (pthread_once_t *once_control, void (*init_routine) (void)) > { > - // already done ? > - if (once_control->state) > + /* Sign bit of once_control->state is used as done flag */ > + if (once_control->state & INT_MIN) > return 0

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Noel Grandin wrote: > > SRW locks are spin-locks. Since they are only pointer-sized, > > ReleaseSRWLockExclusive cannot notify other threads — unlike > > CRITICAL_SECTION. > > Therefore, AcquireSRWLockExclusive must busy-loop when the lock is already > > held. > > > > No, they only spin briefly,

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

On 5/30/2024 10:47 AM, Bruno Haible wrote: SRW locks are spin-locks. Since they are only pointer-sized, ReleaseSRWLockExclusive cannot notify other threads — unlike CRITICAL_SECTION. Therefore, AcquireSRWLockExclusive must busy-loop when the lock is already held. No, they only spin briefly,

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Noel Grandin wrote in cygwin-patches: > Pardon my ignorance, but why not rather use the Windows SRWLock functionality? > https://learn.microsoft.com/en-us/windows/win32/sync/slim-reader-writer--srw--locks > > SRW locks are very fast, only require a single pointer-sized storage area, > can be stat

Re: [PATCH] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

Takashi Yano wrote in cygwin-patches: > To avoid race issues, pthread::once() uses pthread_mutex. This caused > the handle leak which was fixed by the commit 2c5433e5da82. However, > this fix introduced another race issue, i.e., the mutex may be used > after it is destroyed. With th

Re: [URGENT] Issue relating to cygwin

>Dear team, >Please help me check the issue below: > >C:\ESO\RTA-QualityKit\create_project.py:105: SyntaxWarning: "is not" with >'str' literal. Did you mean "!="? > if(qa.name is not 'QA4'): > 0 [main] cntlm 25920 find_fast_cwd:

[URGENT] Issue relating to cygwin

Dear team, Please help me check the issue below: C:\ESO\RTA-QualityKit\create_project.py:105: SyntaxWarning: "is not" with 'str' literal. Did you mean "!="? if(qa.name is not 'QA4'): 0 [main] cntlm 25920 find_fast_cwd: WARNING: Couldn't c

Re: Issue with cygdrive mount, native symlinks, and noacl option

ygdrive mounts (I'm aware of the POSIX vs windows ACL issues, etc. hence > why I use "noacl" for cygdrive). I was able to track down the issue to a > specific combination of things that creates the problem: > 1. I have symlinks in / for each drive pointing to /cygdrive/[a-

Issue with cygdrive mount, native symlinks, and noacl option

s windows ACL issues, etc. hence why I use "noacl" for cygdrive). I was able to track down the issue to a specific combination of things that creates the problem: 1. I have symlinks in / for each drive pointing to /cygdrive/[a-z] via ln -s /cygdrive/ /. 2. All symlinks are actually na

Re: Linux xz issue

On Sun, Mar 31, 2024 at 9:15 PM Keith Thompson wrote: > > Achim Gratz strom...@nexgo.de wrote: > > Beyond that, the version 5.4.6 that everybody is currently reverting to > > (and is also still available for Cygwin if you want to go back) was > > already released when the presumed bad actor was co

Re: Linux xz issue

Achim Gratz strom...@nexgo.de wrote: > Beyond that, the version 5.4.6 that everybody is currently reverting to > (and is also still available for Cygwin if you want to go back) was > already released when the presumed bad actor was co-maintainer and their > involvement goes back even farther based

Re: Linux xz issue

Am 29.03.2024 um 23:43 schrieb Ron Murray via Cygwin: There is a serious security issue with xz (and liblzma) versions 5.6.0-1 and 5.6.1-1. I note that cywin currently is suggesting an upgrade to 5.6.1-1, which is unsafe. I've looked at the cygwin archives and I don't see a referen

Linux xz issue

There is a serious security issue with xz (and liblzma) versions 5.6.0-1 and 5.6.1-1. I note that cywin currently is suggesting an upgrade to 5.6.1-1, which is unsafe. I've looked at the cygwin archives and I don't see a reference to this: sorry if you're already awar

Re: having a cntlm issue

>Hello, Im getting an error when I try to run `cntlm -v` in command prompt >1 [main] cntlm 23520 find_fast_cwd: WARNING: Couldn't compute FAST_CWD >pointer. Please report this problem to >the public mailing list cygwin@cygwin.com > MS-DOS style path detected: C:\Progr

having a cntlm issue

Hello, Im getting an error when I try to run `cntlm -v` in command prompt 1 [main] cntlm 23520 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to the public mailing list cygwin@cygwin.com MS-DOS style path detected: C:\Program Fi

'sh.'exe' issue with redirection

Hello list, my 1st issue here. I'm now having a big issue with 'sh.exe' used by *any* GNU-make program in a link-macro (or simple rule) where 'stdout' gets redirect like this: LDFLAGS = -nologo -debug -incremental:no -verbose define link_EXE @echo -e &

Re: fish shell config issue starting 3.6.4 package

> > I have adjusted the dependencies for fish 3.6.4 and 3.7.0 in the package > > repository on sourceware to add procps-ng. > > > > If this is correct, please remember to make this adjustment in future > > packages. > > Ouch! Sorry everybody! And thank you Xavier, for reporting that. > > Yes,

Re: fish shell config issue starting 3.6.4 package

> >> Since fish shell has been updated to 3.6.4 at the beginning of the > >> year, I > >> obtain a configuration error: > >> > >> fish: Unknown command: pgrep > >> /etc/fish/conf.d/01_fish_variables.fish (line 13): > >> pgrep fish | grep -v \^$fish_pid\$ | xargs -r kill > >>

Re: fish shell config issue starting 3.6.4 package

during startup It seems like default fish configuration relies on pgrep which is not found on Cygwin. Same issue occurs also with 3.7.0. [...] Hi Xavier, it seems a missing dependency pgrep is part of procps-ng package $ cygcheck -p bin/pgrep Found 10 matches for bin/pgrep busybox-1.23.2-1

Re: fish shell config issue starting 3.6.4 package

relies on pgrep which is not found on Cygwin. Same issue occurs also with 3.7.0. Regards, Xavier Hi Xavier, it seems a missing dependency pgrep is part of procps-ng package $ cygcheck -p bin/pgrep Found 10 matches for bin/pgrep busybox-1.23.2-1 - busybox: Tiny utilities in a single

fish shell config issue starting 3.6.4 package

sourcing file /etc/fish/conf.d/01_fish_variables.fish called on line 248 of file /usr/share/fish/config.fish from sourcing file /usr/share/fish/config.fish called during startup It seems like default fish configuration relies on pgrep which is not found on Cygwin. Same issue occurs

Re: Python C Extension Module loading issue on Cygwin

On 11/27/2023 12:49 PM, Marco Atzeri via Cygwin wrote: On 22.09.2023 08:39, Mesibo Technical via Cygwin wrote: This issue is about Python on Cygwin not using the recommended module extension. [cut] Any idea why Cygwin is using the .dll extension instead of the .pyd extension as recommended by

Re: Python C Extension Module loading issue on Cygwin

On 22.09.2023 08:39, Mesibo Technical via Cygwin wrote: This issue is about Python on Cygwin not using the recommended module extension. [cut] Any idea why Cygwin is using the .dll extension instead of the .pyd extension as recommended by Python's official documentation? Additionally, is

Re: Python C Extension Module loading issue on Cygwin

On 9/22/2023 3:39 PM, Mesibo Technical via Cygwin wrote: Any idea why Cygwin is using the .dll extension instead of the .pyd extension as recommended by Python's official documentation? $ grep "_SUFFIX=" /usr/lib/python3.9/config-3.9-x86_64-cygwin/Makefile SHLIB_SUFFIX= .dll EXT_SUFFIX= .

Re: cygwin coreutils 9.4 install.exe issue

On 2023-09-22 07:07, Christoph Reiter wrote: it did a quick test of the coreutils rebase here https://cygwin.com/cgit/cygwin-packages/coreutils/log/?h=playground and noticed that "install" has a regression, in that "install " fails in case the target filename already exits. I did a bit of debug

Python C Extension Module loading issue on Cygwin

This issue is about Python on Cygwin not using the recommended module extension. We have a real-time messaging Python module (https://pypi.org/project/mesibo/) available on various platforms, including Linux, macOS, Windows, and Raspberry Pi. It is written in C/C++ and has been working correctly

Re: posix thread scaling issue

jeff via Cygwin writes: > According to the task manager, it says 'Sockets: 1'. That number doesn't matter at all. When you have more than 64 logical processors, you will have processor groups regardless of topology. Below that threshold processor group configuration can be influenced both by BIOS

Re: posix thread scaling issue

Sorry, I mis-spoke in my previous post... Mark Geisert via Cygwin wrote:   Briefly, you can't move a thread outside the processor group it's currently in; you have to move its process to the new group first. That's backward. You can't add a pr

Re: posix thread scaling issue

Hi folks, Brian Inglis via Cygwin wrote: On 2023-09-02 12:27, jeff via Cygwin wrote: [...] When I run cinebench, I can get to 100% cpu utulization (at around 3ghz) on windows. Chances are the benchmark is designed to handle that: "When the program is running inside the group, unless it is p

Re: posix thread scaling issue

Jeff wrote: > Thanks. I am doing the memory allocation in a single thread. > The compute uses all the threads I can get, and the compute isn't > scaling very well with cygwin. > It does work well on my 16 core 32 thread processor, so for most people > the posix threading is fine. > jeff For t

Re: posix thread scaling issue

On 9/2/2023 12:59, Brian Inglis wrote: On 2023-09-02 12:27, jeff via Cygwin wrote: On 9/2/2023 10:56, Brian Inglis wrote: On 2023-09-02 08:57, jeff via Cygwin wrote: I have a program that is embarrassing parallel. On my older computer which has an epyc 7302 (16 cores,  32 threads) it scales v

Re: posix thread scaling issue

actice, but the new and old processors typically run at about 3ghz when under load. When idling, both processors use about the same amount of power. I have 128gb of ram, in 4 slots. Using that configuration, I can get 100% load and significant faster performance on linux. Therefore I conclude t

Re: posix thread scaling issue

Jeff wrote: > I have a program that is embarrassing parallel. > On my older computer which has an epyc 7302 (16 cores, 32 threads) it > scales very well using cygwin, and fully utilized all threads. > On my new computer which has an epyc 7B13 (64 cores, 128 threads) it > does not scale very well.

Re: posix thread scaling issue

9b6d4ce7b09 In practice, but the new and old processors typically run at about 3ghz when under load. When idling, both processors use about the same amount of power. I have 128gb of ram, in 4 slots. Using that configuration, I can get 100% load and significant faster performance on linux. Therefore I

Re: posix thread scaling issue

On 2023-09-02 08:57, jeff via Cygwin wrote: I have a program that is embarrassing parallel. On my older computer which has an epyc 7302 (16 cores,  32 threads) it scales very well using cygwin, and fully utilized all threads. On my new computer which has an epyc 7B13 (64 cores, 128 threads) it d

posix thread scaling issue

I have a program that is embarrassing parallel. On my older computer which has an epyc 7302 (16 cores,  32 threads) it scales very well using cygwin, and fully utilized all threads. On my new computer which has an epyc 7B13 (64 cores, 128 threads) it does not scale very well. According to the

Re: Deltacopy issue

>Error in rsync protocol data stream >Rsync.exe returned an error. Will try again. This is retry number 3 of 5 >Executing: rsync.exe -v -rlt -z --chmod=a=rw,Da+x --delete >"/cygdrive/D/SMS/" " > 1 [main] rsync 26360 find_fast_cwd: WARNING: Couldn't compute >FAST_CWD pointer. Please report t

Deltacopy issue

Error in rsync protocol data stream Rsync.exe returned an error. Will try again. This is retry number 3 of 5 Executing: rsync.exe -v -rlt -z --chmod=a=rw,Da+x --delete "/cygdrive/D/SMS/" " 1 [main] rsync 26360 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this pr

Re: Permissions question / issue

On Apr 14 15:49, Eliot Moss via Cygwin wrote: > At present I have: > > $ getfacl id_rsa2 > # file: id_rsa2 > # owner: moss > # group: moss > user::rw- > group::--- > group:SYSTEM:r--#effective:--- > mask::--- > other::--- > > $ icacls id_rsa2 > id_rsa2 NULL SID:(DENY)(Rc,DC) > ELI

  1   2   3   4   5   6   7   8   9   10   >