Re: [gcc] Bug in emutls?
On 2025年11月18日, Takashi Yano via Cygwin wrote:> Hi Jeremy,>> On 2025年11月17日 11:16:41 -0800 (PST)> Jeremy Drake wrote:>> On Sat, 8 Nov 2025, Takashi Yano via Cygwin wrote:>>>>> I looked into the problem, and found that the executable for>>> the following code registers two p
Re: [gcc] Bug in emutls?
On Sat, 8 Nov 2025, Takashi Yano via Cygwin wrote:> I looked into the problem, and found that the executable for> the following code registers two pthread_keys with each destructor;> one is void emutls_destroy(void *ptr) in libgcc/emutls.c, and the> other is void run(void *p) in libstdc++-v3/l
Re: Why does Cygwin not use MiCloneProcessAddressSpace() for fork()
On 2025年9月22日, Mark Liam Brown via Cygwin wrote:> Greetings!>> Why does Cygwin not use MiCloneProcessAddressSpace() for fork()? That> function was added for the Windows Services for UNIX, and it still> working in Windows 11.>> Mark> This is a perennial question, and the short answer
debugging hangs in high -j rust builds
I'm trying to debug hangs during rust builds with high -j values. 1. there's a hung "rustc.exe", which I cannot attach gdb to with gdb --pid. I attached with windbg, and it timed out and used some alternate means to attach because the loader lock was held. Is there some way to get gdb to attach
Re: clang 20.1.8+21.1.1: __stdcall__ warning only from Cygwin version
On 2025年9月12日, Christian Franke via Cygwin wrote:> First of all: thanks for providing recent clang packages!>> Testcase:>> $ cat winapi.c> #include > int WINAPI SomeDllFunction(int, int, int, int, int);>> int call_it()> {> return SomeDllFunction(1, 2, 3, 4, 5);> }>> $ clang
Re: clang 20.1.8+21.1.1: __stdcall__ warning only from Cygwin version
On 2025年9月13日, ASSI via Cygwin wrote: > Jeremy Drake via Cygwin writes: > > Another thing that's got me confused in that vicinity is sysv_abi vs > > ms_abi calling convention attribute. I think Cygwin defaults to ms_abi > > so should allow __attribute__((sysv_abi)
Re: clang 20.1.8+21.1.1: __stdcall__ warning only from Cygwin version
On 2025年9月12日, Jeremy Drake via Cygwin wrote: > On 2025年9月12日, Christian Franke via Cygwin wrote: > > > First of all: thanks for providing recent clang packages! > > > > Testcase: > > > > $ cat winapi.c > > #include > > int WINAPI SomeD
Re: clang 20.1.8+21.1.1: __stdcall__ warning only from Cygwin version
On 2025年9月12日, Christian Franke via Cygwin wrote:> First of all: thanks for providing recent clang packages!>> Testcase:>> $ cat winapi.c> #include > int WINAPI SomeDllFunction(int, int, int, int, int);>> int call_it()> {> return SomeDllFunction(1, 2, 3, 4, 5);> }>> $ clang
Re: Building Windows/ARM64 binaries with Cygwin clang?
On Tue, 9 Sep 2025, Mark Liam Brown via Cygwin wrote:> Greetings!>> Can Cygwin 3.7 clang generate Windows/ARM64 binaries somehow?>> My attempts so far are a failure:> clang -target aarch64-pc-windows-gnu -std=gnu17 -Wall -g grapetest1.c> -lntdll -o grapetest1.x86_64.exe> grapetest1.c:34:10
Re: Strange behaviour with Resource Compiler og GCC (MinGW32/64) and LLVM
On Thu, 4 Sep 2025, Thierry DECHAIZE via Cygwin wrote:> Hi,>> I test new implementation of LLVM 20.1.8 recently provided by CYGWIN64 on> WIN11 64 bit.>> Just to illustrated this strange behaviour read joined text : some tests with> different Resource Compiler.>> I'm not a specialist, but
Re: Deploy DLL for ARM64 and AMD64 in the same PATH?
On Wed, 3 Sep 2025, Mark Liam Brown via Cygwin wrote:> Greetings>> Our software needs a 3rd party DLL (we cannot change the name...), but> we want to support ARM64 together with AMD64.>> Does Windows or Cygwin have a mechanism to deal with the situation> that both expects the DLL to be in t
Re: How generate 32 bit format executable with last CLANG 20.1.8
On 2025年8月31日, Thierry DECHAIZE via Cygwin wrote:> Hi,>> Big interest about last version of CLANG 20.1.8 provided with CYGWIN64> (very good job of portability, since "very old" version of CLANG 8.0 ...).>> I can generate application in version 64 bit with this last compiler (on> Wind
Re: Irritating artifacts of the python variety
On 2025年8月22日, Mercurio, Steven W-CTR (FAA) via Cygwin wrote:> Also for Python 3.12 is there any way to get the Cryptography module> (some rust issue?) running so I can pip install the latest version of> Ansible and related tools (or at least something newer than 2.8)?? Rust now builds f
Re: Runtime control per application
On 2025年8月21日, Jeremy Drake via Cygwin wrote: > A potential downside that I see is that settings changes might "leak" into > the parent process that were intended to only take effect for the child. POC: #include #include #include int main (int argc, char **argv) {
Re: Runtime control per application
On 2025年8月18日, Thomas Wolff via Cygwin wrote:> Hi,> a recent patch in MSYS:> https://github.com/msys2/msys2-runtime/commit/cd4b539b367dc2a21041405cb52d3bf5dbf1a3be> supports finer-grained control about runtime behaviour as configured via> MSYS/Cygwin environment.> Maybe it would be a g
Re: another possible setup bug: not accepting "provides" name in -P
On 2025年8月16日, ASSI via Cygwin wrote: > Jeremy Drake via Cygwin writes: > > I was trying to clean up my workflows now that llvm 20.1.8-2 is published, > > and I came across another possible setup bug. It seems that the -P option > > doesn't accept a package na
another possible setup bug: not accepting "provides" name in -P
I was trying to clean up my workflows now that llvm 20.1.8-2 is published, and I came across another possible setup bug. It seems that the -P option doesn't accept a package name that is provided rather than being the actual name of a pacakge. llvm20.1-devel is provided by llvm-devel 20.1.8-2, bu
possible setup bug in /etc/setup/installed.db contents
At least a non-obvious behavior. It seems that packages explicitly selected via the `-P` command line argument are recorded in /etc/setup/installed.db with `0` in the 3rd column, where packages explicitly selected via the GUI are recorded with a `1` in that column. -- Problem reports: https
Re: getting the on-disk case for a path
On Fri, 8 Aug 2025, Jeremy Drake via Cygwin wrote: > On Fri, 8 Aug 2025, Brian Inglis via Cygwin wrote: > > > On 2025年08月08日 00:53, Thomas Wolff via Cygwin wrote: > > > Am 08.08.2025 um 02:31 schrieb Jeremy Drake via Cygwin: > > >> On a case-insensitive but case-
Re: getting the on-disk case for a path
On Fri, 8 Aug 2025, Brian Inglis via Cygwin wrote: > On 2025年08月08日 00:53, Thomas Wolff via Cygwin wrote: > > Am 08.08.2025 um 02:31 schrieb Jeremy Drake via Cygwin: > >> On a case-insensitive but case-preserving filesystem, is there a Cygwin > >> API to get the on-disk
getting the on-disk case for a path
On a case-insensitive but case-preserving filesystem, is there a Cygwin API to get the on-disk case for a given path? It seems like `realpath` ought to do it but running $ touch case-test $ realpath CASE-TEST returns CASE-TEST. Regardless, canonicalize_file_name or realpath may not be what I want
Re: new c++ new/delete overloads need wrapping?
On Sat, 2 Aug 2025, ASSI via Cygwin wrote: > Jeremy Drake via Cygwin writes: > > I was looking into C++ new/delete --wrap linker options, and noticed that > > in a quick test the wrapper for delete was not being called. This was > > because delete is being compiled to _ZdlP
Re: Incorrect command line handling when launching Cygwin program from Windows
On Sat, 2 Aug 2025, Takashi Yano via Cygwin wrote:> On Fri, 1 Aug 2025 15:34:16 +> "Old, Oliver" wrote:>>>>echo-win32.exe C:\"Program Files"\>>> echo-win32.exe>>> C:"Program>>> Files\>>>>>> Is this as you expected?>>>>>>>echo.exe C:\"Program Files"\>>> echo>>>
getcwd() and ENOENT
I have been looking at test failures in LLVM, and I've come across a strange one (to me). It appears to be failing because it expects to: create a temp directory chdir to the temp directory rmdir the temp directory (skip the test if the rmdir fails) call getcwd fail the test if it doesn't get an
Re: Merge posix_spawn() work with CYGWIN env var switch?
On 2025年7月29日, Cedric Blancher via Cygwin wrote:> Good moring!>> Could the posix_spawn() work (branch heads/topic/posix_spawn) be> merged now, but the new version kept off by default unless an option> in the CYGWIN env var is set?>> That would make testing IMO much easier... It coul
Re: new c++ new/delete overloads need wrapping?
On 2025年7月29日, Jeremy Drake via Cygwin wrote: > On 2025年7月29日, Corinna Vinschen via Cygwin wrote: > > > On Jul 28 12:57, Jeremy Drake via Cygwin wrote: > > > On 2025年7月28日, Corinna Vinschen via Cygwin wrote: > > > > Unless there's so
Re: Doubts about whether I can install locally built packages using setup-x86_64.exe
On 2025年7月29日, Jon Turney via Cygwin wrote:> Unfortunately, setup doesn't know how to process standalone packages.>> Your options are described at:>> https://cygwin.com/packaging-contributors-guide.html#installing>>> Yes, this all terrible :( . Someone should make it work better...>
Re: new c++ new/delete overloads need wrapping?
On 2025年7月29日, Corinna Vinschen via Cygwin wrote: > On Jul 28 12:57, Jeremy Drake via Cygwin wrote: > > On 2025年7月28日, Corinna Vinschen via Cygwin wrote: > > > Unless there's some automatism referencing the __wrap_X functions even > > > if the --wrap o
Re: new c++ new/delete overloads need wrapping?
On 2025年7月28日, Corinna Vinschen via Cygwin wrote: > On Jul 25 11:05, Jeremy Drake via Cygwin wrote: > > On 2025年7月25日, Corinna Vinschen via Cygwin wrote: > > > > > On Jul 24 22:41, Jeremy Drake via Cygwin wrote: > > > > I was looking into C++ n
Re: new c++ new/delete overloads need wrapping?
On 2025年7月25日, Corinna Vinschen via Cygwin wrote: > On Jul 24 22:41, Jeremy Drake via Cygwin wrote: > > I was looking into C++ new/delete --wrap linker options, and noticed that > > in a quick test the wrapper for delete was not being called. This was > > because del
Re: new c++ new/delete overloads need wrapping?
On 2025年7月25日, Corinna Vinschen via Cygwin wrote: > On Jul 24 22:41, Jeremy Drake via Cygwin wrote: > > I was looking into C++ new/delete --wrap linker options, and noticed that > > in a quick test the wrapper for delete was not being called. This was > > because del
new c++ new/delete overloads need wrapping?
I was looking into C++ new/delete --wrap linker options, and noticed that in a quick test the wrapper for delete was not being called. This was because delete is being compiled to _ZdlPvm and that symbol is not present in the --wrap arguments in the GCC spec, and is not part of the per_process_cxx
Re: PE format conformance issues in rebase.exe results incompatibility with LLVM-lld
On Sat, 7 Jun 2025, kikairoya via Cygwin wrote:> Dear Cygwin team,>> I’ve found that rebase.exe makes certain assumptions that do not conform> to the PE specification.>> 1. Incorrect handling of COFF File Header position> When checking the 'Characteristics' field in the COFF File Header,>
Re: possible race initializing pgid in spawned child
On Wed, 2 Jul 2025, Corinna Vinschen via Cygwin wrote: > On Jun 30 16:47, Jeremy Drake via Cygwin wrote: > > I cannot duplicate this failure locally, but in GHA the following test > > case fails with > > GHA? GitHub Actions. https://github.com/jeremyd2019/cygwin/actions
issues debugging crash in cygwin dll with gdb
I had an issue in some code I was working on in Cygwin, which resulted in a segfault in the Cygwin dll. It did not work out well though, the process exited with code 0. Attempting to debug with gdb gave [Thread 25728.0x6e60 exited with code 3221225477] [Thread 25728.0x33c0 exited with code 322122
Re: setpgid non-compliance with POSIX?
On Tue, 1 Jul 2025, Brian Inglis via Cygwin wrote: > On 2025年06月30日 13:07, Jeremy Drake via Cygwin wrote: > > On 2025年6月30日, Corinna Vinschen via Cygwin wrote: > > > >> Off the top of my head I don't know how to check the pgid already exists. > >> Do you
possible race initializing pgid in spawned child
I cannot duplicate this failure locally, but in GHA the following test case fails with Process group 0 != expected 704 child exited with code 1 FAIL winsup.api/spawnpgid.exe (exit status: 1) I suspect there must be a race between the child process calling getpgid and the parent running "vchild->p
Re: setpgid non-compliance with POSIX?
On 2025年6月30日, Corinna Vinschen via Cygwin wrote: > On Jun 28 12:32, Jeremy Drake via Cygwin wrote: > > I was looking at setpgid yesterday, and it seems deficient with respect to > > the errors required to be returned by the POSIX docs in > > https://pubs.opengroup.org/
setpgid non-compliance with POSIX?
I was looking at setpgid yesterday, and it seems deficient with respect to the errors required to be returned by the POSIX docs in https://pubs.opengroup.org/onlinepubs/9799919799/functions/setpgid.html Basically, it seems that setpgid allows any arbitrary positive integer to be set as pgid, rathe
Question about PID_NEW_PG in child_info_spawn::worker
I've been poking around in child_info_spawn lately, and I've noticed commit 8d8724ee1b5aa6a1b080c76a0dec3678136d4981 ("Cygwin: pty: Fix Ctrl-C handling further for non-cygwin apps.") added the following (it's since been revised to an InterlockedOr, but that's not relevant to my question): if
Re: XSAVE-related segfaults observed under wine
On 2025年6月27日, Corinna Vinschen via Cygwin wrote:> Hi Pip,>> On Jun 27 14:41, Pip Cet via Cygwin wrote:>> My suggested fix is to align the value in %rbx to the next 64-byte>> multiple after the "cpuid" instruction is executed, by performing the>> assembler equivalent of $rbx += 63;
Re: SIGSEGV in pthread_testcancel() likely due to NULL TLS access (Re: A process spawned inside gem command running on latest ruby segfaults)
On 2025年6月22日, Daisuke Fujimura via Cygwin wrote:> The reproduction procedure could be simplified.>> A segmentation fault (SIGSEGV) occurs when running a Ruby script using> Ruby 3.4.2 (test package) on Cygwin 3.6.3-1 (x86_64), where Thread.new> is used to require 'openssl' inside a thre
Re: Ideas for better powershell<-->Cygwin integration?
On 2025年6月20日, Sebastian Feld via Cygwin wrote:> Does anyone have ideas for a better powershell<-->Cygwin integration?> What features are missing, how could both sides better interact with each > other? Perhaps you would like MSYS2 - it is Cygwin, but with patches to try to make it integ
Re: consistent stress test failures on arm64 after recent signal changes
On 2025年6月18日, Jeremy Drake via Cygwin wrote: > The "stress tests x86_64 on arm64 Windows" tests "fp" and "memcpy" seem to > be consitently failing since 364226a. The step is allowed to continue on > error because there is some flakiness with tests o
consistent stress test failures on arm64 after recent signal changes
The "stress tests x86_64 on arm64 Windows" tests "fp" and "memcpy" seem to be consitently failing since 364226a. The step is allowed to continue on error because there is some flakiness with tests on arm64 Windows, but these tests seem to be pretty consistently failing. It seems like 3 commits we
Re: [EXTERNAL] Cygwin /usr/bin/clang with Windows Aarch64 support?
On 2025年6月17日, Radek Barton via Cygwin wrote:> Hello Sebastian.>> AFAIK, LLVM has no *-pc-cygwin targets support and there is no-one trying to > change that. We're working on that. LLVM 21.x should be much better in that regard. There has been no effort towards aarch64-pc-cygwin though
Re: Cygwin AArch64 testing with Windows AArch64 on qemu?
On 2025年6月17日, Sebastian Feld via Cygwin wrote:> Now that Microsoft is porting Cygwin to Aarch64:>> Do you know how to run Windows Aarch64 in qemu, so people can test> Cygwin Aarch64 changes?>> Sebi Yes, but as others have said it is too slow to really be practical. What I've done la
Re: PTHREAD_MUTEX_INITIALIZER and constinit
On 2025年6月14日, Jeremy Drake via Cygwin wrote: > Consider the following -std=c++20: > #include > > constinit pthread_mutex_t foo = PTHREAD_MUTEX_INITIALIZER; > > With g++ 12.4.0, this succeeds, but with clang 20.1.6 it fails: > pthreadtest.cpp:3:27: error: variable doe
PTHREAD_MUTEX_INITIALIZER and constinit
Consider the following -std=c++20: #include constinit pthread_mutex_t foo = PTHREAD_MUTEX_INITIALIZER; With g++ 12.4.0, this succeeds, but with clang 20.1.6 it fails: pthreadtest.cpp:3:27: error: variable does not have a constant initializer 3 | constinit pthread_mutex_t foo = PTHREAD_MUTEX_
Re: posix_spawn difference from Linux
On 2025年6月13日, Jeremy Drake wrote:> I am working on some posix_spawn tests for the new stc repository [1], and> making sure they behave the same between Cygwin and Linux. I found one> case (so far) which does not: passing NULL for argument "envp" to> posix_spawn.>> In Cygwin, this res
posix_spawn difference from Linux
I am working on some posix_spawn tests for the new stc repository [1], and making sure they behave the same between Cygwin and Linux. I found one case (so far) which does not: passing NULL for argument "envp" to posix_spawn. In Cygwin, this results in the child inheriting the environment from the
Re: Path prefix //./ in Cygwin
On 2025年6月11日, Jeremy Drake via Cygwin wrote: > While making some tests for a path parser in rust > (https://github.com/rust-lang/rust/pull/141864), an interesting corner > case in Cygwin path handling came to light: > > Works: > \\.\C: > //.\C: > //./C:\foo &
Re: Path prefix //./ in Cygwin
On 2025年6月12日, Sam Edge via Cygwin wrote:> I would think that if you're building something against Cygwin, it's probably> best to assume it's POSIX where only forward-slash is special and not try to> second-guess. This is unsafe, and actually where the rust PR started out. If you only t
Path prefix //./ in Cygwin
While making some tests for a path parser in rust (https://github.com/rust-lang/rust/pull/141864), an interesting corner case in Cygwin path handling came to light: Works: \\.\C: //.\C: //./C:\foo Doesn't work: //./C: //./C:/foo It appears to be able to use the \\.\ prefix, there must be at leas
Re: RFE: getconf(1)/|pathconf()| support for |_PC_CASE_SENSITIVE| ...
On Sun, 8 Jun 2025, Brian Inglis via Cygwin wrote: > On 2025年06月07日 19:50, Jeremy Drake via Cygwin wrote: > > On Sun, 8 Jun 2025, Roland Mainz via Cygwin wrote: > > > >> I know... but the request is for portable applications and scripts, > >> which either use |pat
Re: RFE: getconf(1)/|pathconf()| support for |_PC_CASE_SENSITIVE| ...
On Sun, 8 Jun 2025, Roland Mainz via Cygwin wrote:> I know... but the request is for portable applications and scripts,> which either use |pathconf(...,_PC_CASE_SENSITIVE)| or /bin/getconf to> probe this information. Both APIs are not supported by Cygwin yet... Isn't it? https://github.com/cy
instruction cache flushing in Cygwin
I noticed while looking at JIT test failures in LLVM that they don't have an implementation for Cygwin for flushing the instruction cache. I don't see any Cygwin function calling FlushInstructionCache, is there some POSIXy function for this? I don't really want to have to include Windows headers
Re: cygwin 3.6.2-1 under Win11 and win10: XWin.exe fails to start
On Wed, 4 Jun 2025, Don Slutz via Cygwin wrote:> Using 3.6.1-1 works fine. I am very sure this is based on the same issue that > others have reported.>> looks like the key in that I get for "getent passwd $(id -u)":> > NASUNI+dslutz:*:4096:4096:U-NASUNI\dslutz,S-1-12-1-3596282818-121614275
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 2025年5月25日, ASSI via Cygwin wrote: > > > > > > > Jeremy Drake via Cygwin writes: > &
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 2025年5月25日, ASSI via Cygwin wrote: > > > > > Jeremy Drake via Cygwin writes: > > > > Apparently the fix that MSYS2 made for openssl in > > > > h
CCP_WIN_A_TO_POSIX and encodings
In https://github.com/rust-lang/rust/pull/141864 I was going to say that passing an already-posix path through cygwin_conv_path(CPP_WIN_A_TO_POSIX, ...) was unsafe because Windows ANSI file paths are either CP_ACP or CP_OEMCP, while Cygwin POSIX path encodings are based on the C locale encoding (us
Re: openssl and libcurl issue with cargo
On 2025年5月25日, 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 details or sufficient inf
Re: openssl and libcurl issue with cargo
On 2025年5月25日, 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) still reproduces with
Re: openssl and libcurl issue with cargo
On 2025年5月25日, 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 2025年5月25日, 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 li
Re: openssl and libcurl issue with cargo
On 2025年5月24日, 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 >
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: fork error when trying to call VirtualAlloc with size==0
On 2025年5月23日, Yuyi Wang wrote:> On 2025年5月23日, Jeremy Drake wrote:>> Maybe. MSYS2 doesn't generally advise to rebase on x86_64, but I think>> Cygwin does as part of its setup/postinstall hooks. As a hack, I was able>> to work around this by setting the "dynamicbase" flag on t
Re: fork error when trying to call VirtualAlloc with size==0
On 2025年5月23日, Yuyi Wang wrote:> On 2025年5月22日, Jeremy Drake wrote:>> Ultimately, playing whack-a-mole in a 64-bit address space hoping that the>> DLL will load in the same place as the parent is an exercise in futility,>> especially in only 6 attempts.>> Outside cygwin, rustc
Re: fork error when trying to call VirtualAlloc with size==0
On 2025年5月21日, Jeremy Drake via Cygwin wrote: > On 2025年5月21日, Jeremy Drake via Cygwin wrote: > > > the child to not be very fruitful, but maybe there's some debugging to be > > done there > > Well, found the bug that results in a 0 size. size is a
Re: fork error when trying to call VirtualAlloc with size==0
On 2025年5月21日, Jeremy Drake via Cygwin wrote: > the child to not be very fruitful, but maybe there's some debugging to be > done there Well, found the bug that results in a 0 size. size is a DWORD, but mb.RegionSize is 0x2. mb.RegionSize is SIZE_T, but I figur
Re: fork error when trying to call VirtualAlloc with size==0
On 2025年5月20日, Yuyi Wang wrote:> Thank you for your reply. The DLL is a "proc macro" DLL for rustc, which means> that it's not designed to be changed after created. However, I've also found> that this stage-1 compiler doesn't always trigger this failure: it just > trigger> fork failure
Re: fork error when trying to call VirtualAlloc with size==0
On 2025年5月19日, Yuyi Wang via Cygwin wrote:> Recently I'm trying to build rustc on Cygwin (actually MSYS2). Here is the > error:>> 0 [main] rustc 3299 child_info_fork::abort: couldn't allocate memory > 0x1FD10(0) for > '\??\D:\Straw\Documents\Git\rust\build\x86_64-pc-cygwin\st
Re: Signing cygwin.com binaries with signtool by default ?
On Sat, 3 May 2025, Brian Inglis via Cygwin wrote:> On 2025年05月03日 12:21, Roland Mainz via Cygwin wrote:>> Is it somehow possible that the CI+Release binaries (*.exe, *.dll) can>> be signed with signtool>> (https://learn.microsoft.com/en-us/windows/win32/seccrypto/signtool)?>> No - would b
Re: cygwin_conv_path with size 0
On 2025年4月28日, Jeremy Drake via Cygwin wrote: > I was just describing cygwin_conv_path on a rust issue > (https://github.com/rust-lang/backtrace-rs/pull/704). I was saying that > the pointer `to` is not accessed when `size` is 0, but it turns out on > circa line 4022 in pa
cygwin_conv_path with size 0
I was just describing cygwin_conv_path on a rust issue (https://github.com/rust-lang/backtrace-rs/pull/704). I was saying that the pointer `to` is not accessed when `size` is 0, but it turns out on circa line 4022 in path.cc to = (void *) wcpcpy ((wchar_t *) to, ro_u_globalroot.Buffer); This is
Re: Windows 10 Home and sshfs
On 2025年4月27日, David Christensen wrote: > On 4/27/25 14:59, Jeremy Drake wrote: > > On 2025年4月27日, Jeremy Drake via Cygwin wrote: > > > Does sshfs.exe have any exports? Should it? > > > Thank you for the reply. > > > I do not know how to ans
Re: Windows 10 Home and sshfs
On 2025年4月27日, Jeremy Drake via Cygwin wrote: > On 2025年4月27日, David Christensen via Cygwin wrote: > > > The procedure entry point cygfuse_report could not be > > located in the dynamic link library C:\cygwin64\sshfs.exe. > > -> OK > > Does sshfs
enumerating loaded modules on Cygwin
I was asked an interesting question on a github issue about rust backtraces: is there an API in Cygwin to get a list of loaded modules? I know the info is there in the dlls list, but I don't see an API to get at it. The question was in regards to whether rust should be using toolhelp32 on Cygwin
Re: Windows 10 Home and sshfs
On 2025年4月27日, David Christensen via Cygwin wrote:> The procedure entry point cygfuse_report could not be> located in the dynamic link library C:\cygwin64\sshfs.exe.> -> OK Does sshfs.exe have any exports? Should it? (It is legal for an exe to have exports, and for a DLL to reference t
Re: Rust for cygwin (was Re: Deadlock when calling pthread_key_create in the destructor of a pthread_key)
On 2025年4月20日, Takashi Yano via Cygwin wrote:> Is there any other blocker to build Rust for cygwin? https://github.com/rust-lang/rust/issues/137819 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwi
Re: Rust for cygwin (was Re: Deadlock when calling pthread_key_create in the destructor of a pthread_key)
On 2025年4月20日, Takashi Yano via Cygwin wrote:> On 2025年3月24日 14:41:19 +0800> Yuyi Wang wrote:>>> I mean it is some kind of cross compiler.>>>> Yes. Rustc is a cross compiler powered by LLVM.>>>>> ...is it possible to build Rust compiler itself by the cross-compiler?>>>
Re: /dev/null regression in Cygwin 3.6.1
On 2025年4月14日, Bruno Haible via Cygwin wrote:> Especially since this commit modified select.cc, removing a comment> /* TODO: Buffer really full or non-Cygwin reader? */> and here we are exactly in that case: a non-Cygwin process reading from> Cygwin's /dev/null. That's Cygwin's select
Re: Modify bash shell script so it runs in elevated admin mode on Win explorer double click?
On 2025年4月11日, Andrey Repin via Cygwin wrote:> Though, I'm using takecommand's free runtime (TCC-RT), which has an explicit> START /ELEVATED command, and I'm using a wrapper for such tasks. cygutils' cygstart -a runas /bin/bash ... ? -- Problem reports: https://cygwin.com/problems.
Re: pthread_atfork vs dlopen/dlclose
On 2025年4月10日, Corinna Vinschen via Cygwin wrote:>> It seems glibc takes care of this implicit deregistration in>> __cxa_finalize, after calling __cxa_atexit functions, it unregisters any>> at_quick_exit or pthread_atfork callbacks from the DSO being unloaded.>>>> https://sourcewar
Re: ctrl-c issues in 3.6.1?
On 2025年4月10日, Takashi Yano via Cygwin wrote:> On Wed, 9 Apr 2025 16:41:18 -0700 (PDT)> Jeremy Drake wrote:>> I've been doing some building with cmake 4.0.0 and ninja 1.12.1 (of>> llvm/clang, we've got something that seems to mostly work for a cygwin>> target), and I'm noticing after
Re: pthread_atfork vs dlopen/dlclose
On Wed, 9 Apr 2025, Jeremy Drake via Cygwin wrote: > On 2025年4月10日, Kevin Schnitzius via Cygwin wrote: > > > On Wednesday, April 9, 2025 at 06:54:34 PM EDT, Jeremy Drake via Cygwin > > wrote: > > > > > The recent issue with pthread_atfork handlers remin
Re: pthread_atfork vs dlopen/dlclose
On 2025年4月10日, Kevin Schnitzius via Cygwin wrote: > On Wednesday, April 9, 2025 at 06:54:34 PM EDT, Jeremy Drake via Cygwin > wrote: > > > The recent issue with pthread_atfork handlers reminded me of a scenario > > that I know glibc handles, but it seems that Cygwin
ctrl-c issues in 3.6.1?
I've been doing some building with cmake 4.0.0 and ninja 1.12.1 (of llvm/clang, we've got something that seems to mostly work for a cygwin target), and I'm noticing after updating to 3.6.1 it no longer seems to cancel the build when I hit Ctrl-C (previously I was still on 3.5 due to the cmake/ninja
pthread_atfork vs dlopen/dlclose
The recent issue with pthread_atfork handlers reminded me of a scenario that I know glibc handles, but it seems that Cygwin does not. Test case: == test.c == #include #include #include #include typedef void(*func_type)(void); int main(void) { int wstatus = 0; func_type func = NULL; vo
Re: dladdr and dll refcount
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
dladdr and dll refcount
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:
Re: Windows Remote Driver Identification Re: Cygwin wishlist for NFSv4.2 driver?
On Wed, 2 Apr 2025, Cedric Blancher via Cygwin wrote:> On Tue, 1 Apr 2025 at 13:54, Corinna Vinschen via Cygwin> wrote:>> No, but if we want to *better* support this driver, we need either a>> patch (preferred) or at least info how to distinguish in>> fs_info::update(*) between the MSFT d
Re: Crashes in cmake subprocesses since 3.6.0
On Thu, 3 Apr 2025, Takashi Yano via Cygwin wrote:> It seems that raw_write() is called before returning from> pthread::atforkchild() in fork::child().>> Moving _my_tls.fixup_after_fork() before atforkchild() seems> to solve the issue.>> What about:> ld_preload ();> fixup_hooks_after_fork
Re: Crashes in cmake subprocesses since 3.6.0
On 2025年3月31日, Christoph Reiter via Cygwin wrote:> Starting with 3.6.0 when cmake calls into make/ninja/gcc there is a chance of> that failing, for example like this:>> CMake Error: Generator: build tool execution failed, command was:> /usr/bin/cmake.exe -E env VERBOSE=1 /usr/bin/make.e
Re: cmake 4.0.0 fails to build with cygwin 3.7.0-0.19
On 2025年3月31日, Corinna Vinschen via Cygwin wrote: > On Mar 30 14:02, Jeremy Drake via Cygwin wrote: > > I kind of think > > https://github.com/Kitware/CMake/blob/5978c57c20b762a5aeb4b00f31a51a090d670430/Utilities/cmcurl/CMakeLists.txt#L165 > > should match "^(Lin
Re: cmake 4.0.0 fails to build with cygwin 3.7.0-0.19
On 2025年3月30日, Jeremy Drake via Cygwin wrote: > I tried to build cmake 4.0.0 with latest test gcc and cygwin packages, and > got the following error > > /home/WDAGUtilityAccount/cmake-4.0.0/Utilities/cmcurl/lib/rand.c: In > function ‘weak_random’: > /home/WDAGUtilityA
cmake 4.0.0 fails to build with cygwin 3.7.0-0.19
I tried to build cmake 4.0.0 with latest test gcc and cygwin packages, and got the following error /home/WDAGUtilityAccount/cmake-4.0.0/Utilities/cmcurl/lib/rand.c: In function ‘weak_random’: /home/WDAGUtilityAccount/cmake-4.0.0/Utilities/cmcurl/lib/rand.c:124:21: error: implicit declaration of fu
Re: sshd times out and disconnects client
On 2025年3月29日, Soren via Cygwin wrote:> I'll add a bit more information in hopes that we can still find a fix. This> Windows 10 laptop goes into "sleep mode" after a couple hours of no> keyboard or mouse input, and when it does so sshd disconnects any sessions.>> Also, I remember hearin
Re: IO_REPARSE_TAG_LX_SYMLINK supported in Cygwin 3.3?
On Tue, 4 Mar 2025, Cedric Blancher via Cygwin wrote:> Good evening!>> Is IO_REPARSE_TAG_LX_SYMLINK supported in Cygwin 3.3?>> Ced Use the Source, Luke https://sourceware.org/cgit/newlib-cygwin/tree/winsup/cygwin/path.cc?h=cygwin-3_3-branch#n2625 (that's the reading part, the making part i