On Wed, 18 Jun 2025, 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
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
On Tue, 17 Jun 2025, 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
On Tue, 17 Jun 2025, 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
On Sat, 14 Jun 2025, 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
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_
On Fri, 13 Jun 2025, 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
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
On Wed, 11 Jun 2025, 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
&
On Thu, 12 Jun 2025, 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
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
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
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
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
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
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:
> &
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
> > > > h
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
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 details or sufficient inf
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)
still reproduces with
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
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 li
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
>
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
On Fri, 23 May 2025, Yuyi Wang wrote:
> On Fri, 23 May 2025, 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
On Fri, 23 May 2025, Yuyi Wang wrote:
> On Wed, 22 May 2025, 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
On Wed, 21 May 2025, Jeremy Drake via Cygwin wrote:
> On Wed, 21 May 2025, 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
On Wed, 21 May 2025, 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
On Tue, 20 May 2025, 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
On Mon, 19 May 2025, 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
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
On Mon, 28 Apr 2025, 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
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
On Sun, 27 Apr 2025, David Christensen wrote:
> On 4/27/25 14:59, Jeremy Drake wrote:
> > On Sun, 27 Apr 2025, 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
On Sun, 27 Apr 2025, Jeremy Drake via Cygwin wrote:
> On Sun, 27 Apr 2025, 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
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
On Sun, 27 Apr 2025, 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
On Sun, 20 Apr 2025, 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
On Sun, 20 Apr 2025, Takashi Yano via Cygwin wrote:
> On Mon, 24 Mar 2025 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?
> >
>
On Mon, 14 Apr 2025, 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
On Fri, 11 Apr 2025, 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.
On Thu, 10 Apr 2025, 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
On Thu, 10 Apr 2025, 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
On Wed, 9 Apr 2025, Jeremy Drake via Cygwin wrote:
> On Thu, 10 Apr 2025, 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
On Thu, 10 Apr 2025, 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
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
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
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
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:
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
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
On Mon, 31 Mar 2025, 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
On Mon, 31 Mar 2025, 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
On Sun, 30 Mar 2025, 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
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
On Sat, 29 Mar 2025, 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
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
On Fri, 21 Feb 2025, Jeremy Drake via Cygwin wrote:
> I rebased msys2's msys2-runtime fork of cygwin on top of cygwin's master
> branch, and then rebased git-for-windows' msys2-runtime on top of THAT.
>
> 1. Git for Windows's test suite still passes with that (wh
b,
newline, hash, backslash) are now escaped within records as octal \NNN.
In the below snippet, I only convert to delimited by \0 *after*
unescaping, when spaces or newlines may be present in the entries.
> On Sun, Mar 2, 2025 at 10:57 PM Jeremy Drake via Cygwin
> wrote:
>
> > #
On Sun, 2 Mar 2025, Jeremy Drake via Cygwin wrote:
> > 2) assuming there is not, I want to make a script using only things
> > present in a "base system" to clean them up.
>
> Now that the mount points are escaped and contain the Windows volume roots
> starting
On Mon, 3 Jun 2024, Jeremy Drake via Cygwin wrote:
> I'm not necessarily sure that the subject is clear enough, so I want to be
> explicit that I'm talking about files (or I guess potentially directories,
> though I've never seen that) generated by the `try_to_bin` fun
On Thu, 27 Feb 2025, Jan Nijtmans via Cygwin wrote:
> Hi all,
>
> I'll try to find time to update this, in the coming weeks. The problem is
> that
> sqlite for cygwin has some cygwin-specific changes, which were never
> accepted upstream. So it's not trivial to do that. An additional problem
> is
On Tue, 25 Feb 2025, Takeshi Nishimura via Cygwin wrote:
> No, it's beegfs.sys you install.
> SMB is not used, it uses its own protocol. If you do a
> FileRemoteProtocolInfo query the protocol field says it's a
> WNNC_NET_RDR2SAMPLE.
Always nice when a driver doesn't change "sample" idenfiers. I
On Tue, 25 Feb 2025, Cedric Blancher via Cygwin wrote:
> WebDAV and BeeGFS are not alone, the Windows ms-nfs41-client and
> ms-nfs42-client ALWAYS (even with default NFSv4.1 port TCP/2049) use
> UNC paths with "@" character, like
> \\stripe02.zebracluster.intra.pasteur.fr@2049\nfs4\disk02\
> OpenT
On Sat, 22 Feb 2025, Corinna Vinschen via Cygwin wrote:
> On Feb 21 14:35, Jeremy Drake via Cygwin wrote:
> > 2. This seems to have fixed a severe performance regression in Curl's test
> > suite (https://github.com/curl/curl/pull/16217) that I was recently
> > looking
I rebased msys2's msys2-runtime fork of cygwin on top of cygwin's master
branch, and then rebased git-for-windows' msys2-runtime on top of THAT.
1. Git for Windows's test suite still passes with that (which is nice, it
tended to hang when we did this with 3.5.5).
2. This seems to have fixed a sev
On Thu, 20 Feb 2025, Roland Mainz via Cygwin wrote:
> > > Same happens with dash and ksh93.
>
> And THAT statement is BAD, because it means basic shell functionality
> is broken, affecting dash/bash/ksh93 - reading that IMO means Cygwin
> has a problem in the pipe/fifo code... ;-(
>
> Best way for
On Tue, 18 Feb 2025, Corinna Vinschen via Cygwin wrote:
> On Feb 18 11:19, Jeremy Drake via Cygwin wrote:
> > On Tue, 18 Feb 2025, Corinna Vinschen via Cygwin wrote:
> >
> > > Yep. Are you going to create a patch?
> >
> > I'm not seeing a parti
On Tue, 18 Feb 2025, Corinna Vinschen via Cygwin wrote:
> Yep. Are you going to create a patch?
I'm not seeing a particularly clean way to do this. Bring back
available_drives, mask off bits when we see the corresponding drive root
from dos_drive_mappings, and return those drive letters whose bi
On Tue, 18 Feb 2025, Cedric Blancher via Cygwin wrote:
> Good evening!
>
> Cygwin 3.6.0-0.374.g4dd859d01c22.x86_64 on Win10/AMD64/64bit:
>
> df -k no longer shows the data of SMB filesystems, e.g. mount points
> N:-Z: are mounted, but df -k shows nothing:
Ugh, do we have to somehow union volume m
On Mon, 17 Feb 2025, Corinna Vinschen wrote:
> The requirements of posix_spawn and their helper functions are so
> that we can't easily fulfill them without doing the fork/exec
> twist.
>
> See https://man7.org/linux/man-pages/man3/posix_spawn.3.html.
> Windows CreateProcess() is not quite the sam
On Mon, 17 Feb 2025, Corinna Vinschen via Cygwin wrote:
> In fact, I can reproduce this occassionally back to 3.5.0 and back to
> OpenSSH 9.7p1. We can't easily try this with older Cygwin versions.
> It's getting increasingly hard to build older Cygwin versions due to
> compiler dependencies and
On Sat, 8 Feb 2025, Corinna Vinschen via Cygwin wrote:
> Go for it. There's already matching logic in fhandler/proc.cc,
> function format_proc_partitions() for the "win-mounts" column
> of /proc/partitions. Probably this can be reused.
Actually closer to the dos_drive_mappings at the end of mou
On Fri, 7 Feb 2025, Roland Mainz via Cygwin wrote:
> Hi!
>
>
>
> [Slightly offtopic, but I am banging my head against this problem most
> of the day]
> What symlink value should |MRxCreate()| return on |STATUS_REPARSE| to
> redirect to another DOS drive or UNC path ? I tried something like
>
On Fri, 7 Feb 2025, Corinna Vinschen via Cygwin wrote:
> On Feb 6 13:31, Jeremy Drake via Cygwin wrote:
> > Now that my patch to escape characters in /proc/mounts has been applied,
> > I'll get back to what I was thinking about back in June. I would like to
> > have a
Now that my patch to escape characters in /proc/mounts has been applied,
I'll get back to what I was thinking about back in June. I would like to
have a way to list Windows volume roots in Cygwin, and it seems to make
sense to me to expose them via getmntent, /proc/mounts, etc. The way I
see this
We were attempting to build util-linux 2.40.2 for MSYS2, based on the
source package of util-linux-2.40.2-2 from Cygwin [1]. We were scratching
our heads as to why it wasn't building tasksel for us, when it did in your
package. I evenutally saw in the cygport that it tests for sys/syscall.h
and w
On Tue, 4 Feb 2025, Roland Mainz via Cygwin wrote:
> it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for
> "remote" filesystems:
> snip
> 2582/* Don't handle junctions on remote filesystems as
> symlinks. This type
> 2583 of reparse point is handl
On Tue, 14 Jan 2025, Takashi Yano via Cygwin wrote:
> Personally, I personally prefer releasing 3.5.6 ASAP.
Is this the plan, now that the hangs seem to be resolved? (Maybe after
additional confirmation/testing?)
--
Problem reports: https://cygwin.com/problems.html
FAQ: h
On Tue, 21 Jan 2025, Jeremy Drake via Cygwin wrote:
> I did not see this happen with ruby 3.3.7, or when building with -j1.
Sorry, spoke too soon, I did see this immediately with 3.3.7 as well.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.
I've been trying to track down why ruby 3.4.1 is failing to build for
msys2. I've now confirmed that this same issue reproduces with
upstream Cygwin 3.5.4 and 3.6.0-0.335.gb879cd1661ad, so I thought I'd
bring it up here:
when building ruby with a high -j value (I'm doing make -j21), I get
errors
On Tue, 14 Jan 2025, Takashi Yano via Cygwin wrote:
> Hi Michael,
>
> Personally, I personally prefer releasing 3.5.6 ASAP. However, we
> are not sure that we have already fixed all the major problems in
> 3.5.5.
>
> Can you please test latest cygwin 3.6.0 (TEST) whether the your
> CI issue still
There are known (and as yet unknown) hang issues with cygwin 3.5.5, the
known being in signal handling. You might try with cygwin 3.5.4 to see if
your hang issues go away. That might help elimiate python as the culprit.
On Fri, 3 Jan 2025, Michael Cook via Cygwin wrote:
> The hangs I've looked
On Wed, 25 Dec 2024, Jeremy Drake via Cygwin wrote:
> We ran into hang issues with libtool linking imagemagick in msys2, using
> version based on 3.5.5, 3 times in a row on our ARM64 runner. We applied
> your v2 patch to our 3.5.5 branch (with the change of current_sig to sig),
> a
On Wed, 25 Dec 2024, Takashi Yano via Cygwin wrote:
> On Tue, 24 Dec 2024 22:34:44 +0100
> Bruno Haible wrote:
> > This is not reproducible, but here's the report anyway:
> >
> > I upgraded a Windows 10 system from Cygwin 3.5.3 to 3.5.5 today.
> > Then ran the configure script of a tarball (*), an
On Sat, 23 Nov 2024, Cedric Blancher via Cygwin wrote:
> Good afternoon!
>
> Does Cygwin do a silly rename if a Cygwin file is open but gets
> /bin/rm at the same time?
Yes! See function try_to_bin in winsup/cygwin/syscalls.cc:
/* Create unique filename. Start with a dot, followed by "cyg
On Thu, 21 Nov 2024, Corinna Vinschen via Cygwin wrote:
> IMHO:
>
> if (IsWow64Process2 (GetCurrentProcess (), &emulated, &hosted))
> && emulated != IMAGE_FILE_MACHINE_UNKNOWN)
> if (hosted == IMAGE_FILE_MACHINE_AMD64)
> strcat (sysname, "-WOW64");
> else if (hosted == IMAGE_
On Thu, 21 Nov 2024, Corinna Vinschen via Cygwin wrote:
> > i686x86_64 -WOW64-x64 (or omit arch to match existing?)
>
> Just -WOW64
>
> For backward compat and it's a sole representative of an intel-intel
> emulation anyway. I think we may safely ignore "WOW"
>
> > i686ARM64 -W
On Wed, 20 Nov 2024, Jeremy Drake via Cygwin wrote:
> CygwinHostSuffix
> Not worth worrying about:
> ARM ARM64 -WOW64-ARM (?)
Oops, this should have been -WOW64-ARM64 since the host is ARM64. But
like I said, this case would never happen anyway.
--
Problem reports:
I mentioned this briefly on cygwin-patches during the review of the fix
for a deadlock when running under emulation on ARM64 hosts, but I wanted
to discuss it more thoroughly here now that that is merged.
It seems like it would be useful, perhaps for stats tracking purposes like
MSYS2 does [1], to
On Sat, 28 Sep 2024, Mark Liam Brown via Cygwin wrote:
> On Tue, Sep 17, 2024 at 12:49 PM Mark Liam Brown
> wrote:
> >
> > Greetings!
> >
> > Are there Cygwin 3.6 x86/32bit builds?
> > We're on Windows 10/ARM64, and as Cygwin does not support ARM64 yet
> > the only other option is to use the x86
On Thu, 19 Sep 2024, Brian Inglis via Cygwin wrote:
> On 2024-09-19 07:27, Christian Franke via Cygwin wrote:
> >
> >
> > Yes, but Cygwin does not provide consistent forward/reverse UTF-8 <-> UTF-16
> > mappings.
>
> Surrogates halves are invalid for UTF-8 encoding; they should be first be
> encod
On Sun, 4 Aug 2024, Jeremy Drake via Cygwin wrote:
> TASKKILL /F /IM cygwin1.dll
> to kill them
Oops, make that
TASKKILL /F /FI "MODULES eq cygwin1.dll"
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentati
On Sun, 4 Aug 2024, Brian Inglis via Cygwin wrote:
> Most such problems happen because something has been running and not yet
> terminated before running Cygwin Setup, or Windows Scheduled Tasks running
> Cygwin processes while running Cygwin Setup.
>
> I start Task Manager, tab Details, sort by I
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
On Fri, 14 Jun 2024, Jeremy Drake via Cygwin wrote:
> On Fri, 14 Jun 2024, Jeremy Drake via Cygwin wrote:
>
> > Eliot Moss replied to me privately, and I confirmed as well, that this
> > does not occur with Cygwin 3.5.1-1. So this appears to be a regression
> > in 3.5
On Fri, 14 Jun 2024, Jeremy Drake via Cygwin wrote:
> Eliot Moss replied to me privately, and I confirmed as well, that this
> does not occur with Cygwin 3.5.1-1. So this appears to be a regression
> in 3.5.3.
It also does not occur in 3.6.0-0.81 or 3.6.0-0-0.115, so perhaps this wa
On Thu, 13 Jun 2024, Jeremy Drake via Cygwin wrote:
> Thankfully, this can be simply reproduced with the following two bash
> commands (on cygwin 3.5.3):
>
> mkdir -p foo/$'\uD800'
> rm -rf foo
Eliot Moss replied to me privately, and I confirmed as well, that this
d
On Thu, 13 Jun 2024, Brian Inglis via Cygwin wrote:
> These reserved surrogate values should probably either be blocked, or encoded
> at
> the file system interface layer so they can be round tripped, like the Windows
> reserved characters, in the BMP or SMP PUAs.
>
> Reserved surrogate ranges are
Backstory: rust's test suite makes an oddly-named directory as part of a
test:
https://github.com/rust-lang/rust/blob/921645c737f1d6d107a0a10ca5ee129d364dcd7a/tests/run-make/non-unicode-in-incremental-dir/rmake.rs
When trying to clean up after a rust build/test with rm -rf, it results in
a "Direct
1 - 100 of 134 matches
Mail list logo
