> Why don't you use the cygwin cmake?
We want to use VS Code to work with the project. It doesn't like
Cygwin's CMake. It would also interfere with the clangd language server
since that reads from CMake's compile_commands.json which contains the
command line as it would be used within the shell.
Am 04.08.2025 um 15:03 schrieb Old, Oliver via Cygwin:
BTW, what exactly is the "Windows-native tool"?
A tool built to run on Microsoft's CRT, so not a Cygwin program.
So, shouldn't you be complaining abount PowerShell as well?
I'm only using CMD as a launcher here (and made sure it does no
Am 04.08.2025 um 15:03 schrieb Old, Oliver via Cygwin:
BTW, what exactly is the "Windows-native tool"?
A tool built to run on Microsoft's CRT, so not a Cygwin program.
So, shouldn't you be complaining abount PowerShell as well?
I'm only using CMD as a launcher here (and made sure it does no
> BTW, what exactly is the "Windows-native tool"?
A tool built to run on Microsoft's CRT, so not a Cygwin program.
> So, shouldn't you be complaining abount PowerShell as well?
I'm only using CMD as a launcher here (and made sure it does not modify
the input in unexpected ways). This is not abou
Greetings, Jeremy Drake!
>> cygwin does not treat \ as a quote if it is passed from non-cygwin shell.
>> When a Cygwin program is launched from a non-Cygwin shell, I personally
>> find it more natural for it to follow quoting semantics similar to Bash.
>>
>> I'm afraid that's not the case...
>>
>>
On 2025-08-02 07:30, Bruno Haible via Cygwin wrote:
Hello Jon,
(These can be installed into /usr/src/ using the setup tool, by
selecting "src?" checkbox after locating the appropriate package and
version)
Oh, I completely missed this possibility.
I also missed the possibility to download the
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 _ZdlPvm and that symbol is n
Hello Jon,
> (These can be installed into /usr/src/ using the setup tool, by
> selecting "src?" checkbox after locating the appropriate package and
> version)
Oh, I completely missed this possibility.
I also missed the possibility to download the source package from a
Cygwin packages mirror, s
On 02/08/2025 11:43, Bruno Haible via Cygwin wrote:
The essence of the GPL is:
When someone distributes binaries,
they must distribute the corresponding source code too.
This is
1. a legal requirement,
2. the mechanism that holds the Free Software community together,
3. what allo
Bruno Haible via Cygwin writes:
> So, the corresponding source code is sitting solely on the Cygwin
> maintainer's disk. If they experience a hard disk crash or if the directory
> with that corresponding source code gets lost through an accidental
> "rm -rf", the corresponding source cannot be dist
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 _ZdlPvm and that symbol is not present
> in the --wrap arguments in the GCC spec
Greetings, Old, Oliver!
> Hello!
> I have recently noticed that the Windows command line parsing routine of
> Cygwin programs does not
> work correctly when an escaped quotation mark is included. This is relevant
> when launching a Cygwin-
> based GCC through Windows CMake-generated Ninja files
Am 02.08.2025 um 07:40 schrieb Jeremy Drake via Cygwin:
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"\
ec
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
> > >
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
> > C:\Program Files\
> >
> > This makes more sense to me.
>
> That is as expe
> >echo-win32.exe C:\"Program Files"\
> echo-win32.exe
> C:"Program
> Files\
>
> Is this as you expected?
>
> >echo.exe C:\"Program Files"\
> echo
> C:\Program Files\
>
> This makes more sense to me.
That is as expected. It is the way a Windows program would split the
command line. To me, it does
On Thu, 31 Jul 2025 13:28:14 +
"Old, Oliver via Cygwin" wrote:
> Hello!
>
> I have recently noticed that the Windows command line parsing routine of
> Cygwin programs does not
> work correctly when an escaped quotation mark is included. This is relevant
> when launching a Cygwin-
> based GC
Hello Achim,
(Trying this again with manually entered Cygwin email address since the
reply link does not work in MS Outlook. Sorry for previously emailing
directly.)
Maybe I should have mentioned it. Both invocations are done exactly the
same way through cmd.exe. It does not do anything funny to
Old, Oliver via Cygwin writes:
> Running it (via cmd.exe):
>
>>echo.exe a b\"c\" d
> echo
> a
> b\c" d
That's the expected behaviour from cmd.exe and has nothing to do with
Cygwin, so perhaps you read up on what cmd.exe does with it's command
lines (if you want get both a headache and nausea).
R
Lionel Cons via Cygwin writes:
> I was thinking about a *FUNCTIONAL* test, because the
> setfacl-does-not-work-for-dirs bug in Cygwin caused MASSIVE disruption
> here, and I don't want to see THAT particular bug EVER again.
And for you, too: if you're (cross-)posting to the developers mailing
list
On Wed, 30 Jul 2025 at 18:37, Brian Inglis via Cygwin wrote:
>
> On 2025-07-30 05:11, Lionel Cons wrote:
> > On Tue, 15 Jul 2025 at 19:05, Lionel Cons wrote:
> >>
> >> Does Cygwin have CI tests for setfacl(1),getfacl(1), i.e. which tests
> >> basic usage on NTFS and ReFS? Where can I find this?
>
On 2025-07-30 05:11, Lionel Cons wrote:
On Tue, 15 Jul 2025 at 19:05, Lionel Cons wrote:
Does Cygwin have CI tests for setfacl(1),getfacl(1), i.e. which tests
basic usage on NTFS and ReFS? Where can I find this?
I could not find any tests, at least not in the Cygwin sources. Is
there a separa
Hi Ced,
On Tue, 29 Jul 2025, Cedric Blancher wrote:
> 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...
Actually, no, it wouldn't,
On Tue, 15 Jul 2025 at 19:05, Lionel Cons wrote:
>
> Does Cygwin have CI tests for setfacl(1),getfacl(1), i.e. which tests
> basic usage on NTFS and ReFS? Where can I find this?
I could not find any tests, at least not in the Cygwin sources. Is
there a separate repro for CI? How can I contribute
On Jul 29 14:34, Jeremy Drake via Cygwin wrote:
> On Tue, 29 Jul 2025, Jeremy Drake via Cygwin wrote:
>
> > On Tue, 29 Jul 2025, Corinna Vinschen via Cygwin wrote:
> >
> > > On Jul 28 12:57, Jeremy Drake via Cygwin wrote:
> > > > On Mon, 28 Jul 2025, Corinna Vinschen via Cygwin wrote:
> > > > > Un
On Jul 29 16:22, Jeremy Drake via Cygwin wrote:
> 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 th
On Tue, 29 Jul 2025, 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
On Tue, 29 Jul 2025, Jeremy Drake via Cygwin wrote:
> On Tue, 29 Jul 2025, Corinna Vinschen via Cygwin wrote:
>
> > On Jul 28 12:57, Jeremy Drake via Cygwin wrote:
> > > On Mon, 28 Jul 2025, Corinna Vinschen via Cygwin wrote:
> > > > Unless there's some automatism referencing the __wrap_X function
On 2025-07-29 11:27, Soren via Cygwin wrote:
Hello again good folk,
This week my general confusion has focussed in on installing the
giflib build I did using cygport (I finally found, understood and
followed the instructions for using cygport! Hurray!).
Most packages already have their cygport
On Tue, 29 Jul 2025, 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...
>
On 29/07/2025 18:27, Soren via Cygwin wrote:
Hello again good folk,
This week my general confusion has focussed in on installing the
giflib build I did using cygport (I finally found, understood and
followed the instructions for using cygport! Hurray!).
I then tried to use Setup to install the
On Tue, 29 Jul 2025, Corinna Vinschen via Cygwin wrote:
> On Jul 28 12:57, Jeremy Drake via Cygwin wrote:
> > On Mon, 28 Jul 2025, Corinna Vinschen via Cygwin wrote:
> > > Unless there's some automatism referencing the __wrap_X functions even
> > > if the --wrap option isn't present, I don't see t
On Jul 28 12:57, Jeremy Drake via Cygwin wrote:
> On Mon, 28 Jul 2025, Corinna Vinschen via Cygwin wrote:
> > Unless there's some automatism referencing the __wrap_X functions even
> > if the --wrap option isn't present, I don't see this incompatibility as
> > much of a problem. We're trying to ma
On Tue, 8 Apr 2025 at 12:48, Corinna Vinschen via Cygwin
wrote:
>
> On Apr 3 14:28, Jeremy Drake via Cygwin wrote:
> > 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* supp
On Mon, 28 Jul 2025, Corinna Vinschen via Cygwin wrote:
> On Jul 25 11:05, Jeremy Drake via Cygwin wrote:
> > On Fri, 25 Jul 2025, 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 notic
On Jul 25 11:05, Jeremy Drake via Cygwin wrote:
> On Fri, 25 Jul 2025, 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
On Jul 25 10:28, Jeremy Drake via Cygwin wrote:
> On Fri, 25 Jul 2025, Corinna Vinschen via Cygwin wrote:
> > Nevertheless, the code overriding the members in per_process_cxx_malloc
> > is living in the app (_cygwin_crt0_common.cc). If you just append members
> > to per_process_cxx_malloc nad impl
>iâm currently trying to use a program but i canât as my laptop canât
>compute fast_cwd pointer, may you please update my firmware?
https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://c
Zartaj Majeed via Cygwin writes:
> The latest GCC 13.4 package is not configured with --enable-checking=release
Read the gcc documentation:
When the option is not specified, the active set of checks depends on
context. Namely, bootstrap stage 1 defaults to ‘--enable-checking=yes’,
builds from rel
Zartaj Majeed via Cygwin writes:
> The latest GCC 13.4 package is not configured with --enable-checking=release
Read the gcc documentation:
When the option is not specified, the active set of checks depends on
context. Namely, bootstrap stage 1 defaults to ‘--enable-checking=yes’,
builds from rel
The latest GCC 13.4 package is not configured with --enable-checking=release
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/13/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/mnt/share/packages/gccmake/gcc-13/gcc/gcc.x86_64/src/gcc-13.4
Zartaj Majeed via Cygwin writes:
> GCC on Cygwin is not configured with --enable-checking=release. This
> makes the compiler run very slow due to extra diagnostic checks.
How about you don't install the absolutely latest test version (from a
gcc snapshot) and instead chose a released one? The sta
Hello.
> Did you benchmark WHY it takes so long?
Not really but in general creating Cygwin/MSYS2 processes on Windows (even x64
on x64) has its costs and GNU tools are heavily utilizing creation of overload
of short-living processes. Plus there is a cost of x64 emulation on Arm64 which
is arou
On Fri, 25 Jul 2025, 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 delete is being compiled to
On Fri, 25 Jul 2025, 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 delete is being compiled to
On Tue, Jul 22, 2025 at 10:02 AM Radek Barton
wrote:
>
> Hello.
>
> Thank you for your interest in AArch64 Cygwin.
>
> The changes that has been upstreamed so far are not yet enough to build the
> package itself nor the toolchain necessary to build it. The minimum allowing
> that lives in
> htt
On Tue, Jul 22, 2025 at 10:02 AM Radek Barton
wrote:
> Building x64 Cygwin to AArch64 Cygwin cross-compilation toolchain requires
> some additional changes that are in
> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/compare/main...native-cygwin
> branch. I generally don't re
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 delete is being compiled to _ZdlPvm and that symbol is not present
> in the --wrap arguments
On 2025-07-24 09:36, Corinna Vinschen via Cygwin wrote:
On Jul 24 09:28, Brian Inglis via Cygwin wrote:
On 2025-07-24 04:30, Corinna Vinschen via Cygwin wrote:
Or shall simply go along with CESU-8 when converting back to multibyte
to keep the string the same as with wcstombs?
There are 15 * S
On Jul 24 20:12, Jon Turney via Cygwin wrote:
> On 23/07/2025 09:25, Takashi Yano via Cygwin wrote:
> > On Wed, 23 Jul 2025 17:02:22 +0900
> > Takashi Yano wrote:
> > > Recent cygwin setup-x86_64.exe has Japanese translation and
> > > it uses Japanese when it is running in Japanese Windows.
> > >
On 23/07/2025 09:25, Takashi Yano via Cygwin wrote:
On Wed, 23 Jul 2025 17:02:22 +0900
Takashi Yano wrote:
Recent cygwin setup-x86_64.exe has Japanese translation and
it uses Japanese when it is running in Japanese Windows.
However, sometimes I would like to setup-x86_64.exe with
English. I tri
On Jul 24 19:45, Thomas Wolff via Cygwin wrote:
> Am 24.07.2025 um 17:35 schrieb Corinna Vinschen:
> > Consider the following GB18030 string: 0x90 0x30 0x81 0x30
> >
> > This string translates into a UTF-16 surrogate pair: 0xd800 0xdc00.
> >
> > If you run a tweaked version of your test applicato
Am 24.07.2025 um 17:35 schrieb Corinna Vinschen:
Thomas,
On Jul 23 05:44, Thomas Wolff via Cygwin wrote:
Am 22.07.2025 um 15:05 schrieb Corinna Vinschen:
mbrtowc() is inherently a bad idea when it comes to UTF-16. It's a
function which only works really correctly for the unicode base plane,
o
Am 24.07.2025 um 16:08 schrieb Corinna Vinschen:
On Jul 24 15:41, Thomas Wolff via Cygwin wrote:
Am 24.07.2025 um 12:30 schrieb Corinna Vinschen:
What does that mean? Consider this UTF8 input string:
0xf0 0x90 0x80 0x2e
mbstowcs: returns -1
sys_mbstowcs: f0f0 f090 f080 002e
On Jul 24 09:28, Brian Inglis via Cygwin wrote:
> On 2025-07-24 04:30, Corinna Vinschen via Cygwin wrote:
> > Or shall simply go along with CESU-8 when converting back to multibyte
> > to keep the string the same as with wcstombs?
>
> There are 15 * SMP as BMP characters, so many non-Western and e
Thomas,
On Jul 23 05:44, Thomas Wolff via Cygwin wrote:
> > > Am 22.07.2025 um 15:05 schrieb Corinna Vinschen:
> > > > mbrtowc() is inherently a bad idea when it comes to UTF-16. It's a
> > > > function which only works really correctly for the unicode base plane,
> > > > or if wchar_t is big enou
On 2025-07-24 04:30, Corinna Vinschen via Cygwin wrote:
Hi Thomas, hi Christian,
On Jul 23 17:50, Thomas Wolff via Cygwin wrote:
Am 23.07.2025 um 09:53 schrieb Corinna Vinschen via Cygwin:
On Jul 23 05:44, Thomas Wolff via Cygwin wrote:
What bugs me is that we have the choice between a broken
On Jul 24 15:41, Thomas Wolff via Cygwin wrote:
> Am 24.07.2025 um 12:30 schrieb Corinna Vinschen:
> > What does that mean? Consider this UTF8 input string:
> >
> >0xf0 0x90 0x80 0x2e
> >
> >mbstowcs: returns -1
> >sys_mbstowcs: f0f0 f090 f080 002e
> >
> > Let's convert it back
Am 24.07.2025 um 12:30 schrieb Corinna Vinschen:
Hi Thomas, hi Christian,
On Jul 23 17:50, Thomas Wolff via Cygwin wrote:
Am 23.07.2025 um 09:53 schrieb Corinna Vinschen via Cygwin:
On Jul 23 05:44, Thomas Wolff via Cygwin wrote:
What bugs me is that we have the choice between a broken mbrto
Hi Thomas, hi Christian,
On Jul 23 17:50, Thomas Wolff via Cygwin wrote:
> Am 23.07.2025 um 09:53 schrieb Corinna Vinschen via Cygwin:
> > On Jul 23 05:44, Thomas Wolff via Cygwin wrote:
> > What bugs me is that we have the choice between a broken mbrtowc on
> > one side and a chance to generate b
Am 23.07.2025 um 09:53 schrieb Corinna Vinschen via Cygwin:
On Jul 23 05:44, Thomas Wolff via Cygwin wrote:
OK, suppose I'd consider to switch to mbs[[n]r]towcs, collecting bytes until
the function gives me a result.
This would work fine as long as I receive only valid sequences. But look at
i
On Wed, 23 Jul 2025 17:02:22 +0900
Takashi Yano wrote:
> Recent cygwin setup-x86_64.exe has Japanese translation and
> it uses Japanese when it is running in Japanese Windows.
>
> However, sometimes I would like to setup-x86_64.exe with
> English. I tried:
> LANG=en_US.UTF-8
> LC_ALL=en_US.UTF-8
>
On Jul 23 05:44, Thomas Wolff via Cygwin wrote:
> OK, suppose I'd consider to switch to mbs[[n]r]towcs, collecting bytes until
> the function gives me a result.
> This would work fine as long as I receive only valid sequences. But look at
> input string test case
> char nonbmp[] = {0xF8, 0x88, 0x8A
Am 23.07.2025 um 04:25 schrieb Thomas Wolff via Cygwin:
Am 22.07.2025 um 17:09 schrieb Thomas Wolff via Cygwin:
Am 22.07.2025 um 15:05 schrieb Corinna Vinschen:
On Jul 22 05:38, Thomas Wolff via Cygwin wrote:
Am 27.06.2025 um 12:30 schrieb Corinna Vinschen via Cygwin:
On Jun 26 19:07, C
Am 22.07.2025 um 17:09 schrieb Thomas Wolff via Cygwin:
Am 22.07.2025 um 15:05 schrieb Corinna Vinschen:
On Jul 22 05:38, Thomas Wolff via Cygwin wrote:
Am 27.06.2025 um 12:30 schrieb Corinna Vinschen via Cygwin:
On Jun 26 19:07, Christian Franke via Cygwin wrote:
With some trial and error
>C:\Users\Administrator\Desktop\odhcploc-20110529-bin-cygwin-i386>odhcploc.exe
>10.50.51.79
> 2 [main] odhcploc 17584 find_fast_cwd: WARNING: Couldn't compute
> FAST_CWD pointer. Please report this problem to
>the public mailing list cygwin@cygwin.com
>02:21:32 (IP)10.50.51.181OFFER
On Mon, Jul 21, 2025 at 10:33 AM Aurélien Couderc wrote:
> I think the problem is that Cygwin does not want to list accounts from
> "NT SERVICE" and "NT AUTHORITY", except you prefix that with "+". And
> that makes me mad, because it sucked up the time of around 25 students
> here for 90 mins in t
Am 22.07.2025 um 15:05 schrieb Corinna Vinschen:
On Jul 22 05:38, Thomas Wolff via Cygwin wrote:
Am 27.06.2025 um 12:30 schrieb Corinna Vinschen via Cygwin:
On Jun 26 19:07, Christian Franke via Cygwin wrote:
With some trial and error I found a testcase for this more serious problem
reporte
On Jul 22 05:38, Thomas Wolff via Cygwin wrote:
> Am 27.06.2025 um 12:30 schrieb Corinna Vinschen via Cygwin:
> > On Jun 26 19:07, Christian Franke via Cygwin wrote:
> > > With some trial and error I found a testcase for this more serious problem
> > > reported yesterday but not quoted above:
> > >
Greetings, Soren!
> Cygwin root is C:\ix\cygwin, just so you know.
> CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:67 (message):
> The C compiler
> "/c/ix/cygwin/bin/cc"
That does not match up with your earlier statement of the Cygwin root
location.
Which means, you ar
Hello.
Thank you for your interest in AArch64 Cygwin.
The changes that has been upstreamed so far are not yet enough to build the
package itself nor the toolchain necessary to build it. The minimum allowing
that lives in
https://github.com/Windows-on-ARM-Experiments/newlib-cygwin/compare/upstr
Am 27.06.2025 um 12:30 schrieb Corinna Vinschen via Cygwin:
Hi Christian,
On Jun 26 19:07, Christian Franke via Cygwin wrote:
Corinna Vinschen via Cygwin wrote:
On Jun 25 16:59, Christian Franke via Cygwin wrote:
On Sun, 15 Sep 2024 19:47:11 +0200, Christian Franke wrote:
If a file name con
,
maybe long ago -- maybe you need to re-run it and update your passwd file.
https://cygwin.com/cygwin-ug-net/mkpasswd.html
Preferably delete it and possibly modify /etc/nsswitch.conf:
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch
That file does not exist.
T
Aurélien Couderc via Cygwin writes:
>> > I think you misunderstand me. I am suggesting to improve the Cygwin
>> > implementation of opendir(), readdir() and friends to do Win32/WInNT
>> > calls async to speed up dir listings.
>>
>> If you know how it can be done, why not provide a patch?
>
> Becaus
On Mon, Jul 21, 2025 at 6:08 PM Brian Inglis via Cygwin
wrote:
>
> On 2025-07-21 09:19, Aurélien Couderc via Cygwin wrote:
> > On Fri, Jul 18, 2025 at 12:50 PM Andrey Repin wrote:
> >>
> >> Greetings, Aurélien Couderc!
> >>
> >> Stat and ACL info require additional calls.
>
> > Right
you create a local /etc/passwd file, say, through mkpasswd? If you did,
> > maybe long ago -- maybe you need to re-run it and update your passwd file.
> >
> > https://cygwin.com/cygwin-ug-net/mkpasswd.html
>
> Preferably delete it and possibly modify /etc/nsswitch.conf
On 2025-07-21 09:19, Aurélien Couderc via Cygwin wrote:
On Fri, Jul 18, 2025 at 12:50 PM Andrey Repin wrote:
Greetings, Aurélien Couderc!
Stat and ACL info require additional calls.
Right, but my proposal is to do parallel/async lookups. The Windows NT
kernel depends heavily on multithrea
quot;, both getent
passwd MariaDB and getent passwd return no lines.
Any clues what I am doing wrong?
Did you create a local /etc/passwd file, say, through mkpasswd? If you did,
maybe long ago -- maybe you need to re-run it and update your passwd file.
https://cygwin.com/cygwin-ug-net/mkpasswd.ht
On Fri, Jul 18, 2025 at 12:50 PM Andrey Repin wrote:
>
> Greetings, Aurélien Couderc!
>
> >> >> Stat and ACL info require additional calls.
> >>
> >> > Right, but my proposal is to do parallel/async lookups. The Windows NT
> >> > kernel depends heavily on multithreading and parallelism, of which
>
But Cygwin 3.7 from today cannot see the user "MariaDB", both getent
> > passwd MariaDB and getent passwd return no lines.
> >
> > Any clues what I am doing wrong?
>
> Did you create a local /etc/passwd file, say, through mkpasswd? If you
> did, maybe long ago --
no lines.
Any clues what I am doing wrong?
Did you create a local /etc/passwd file, say, through mkpasswd? If you
did, maybe long ago -- maybe you need to re-run it and update your
passwd file.
https://cygwin.com/cygwin-ug-net/mkpasswd.html
--
Problem reports: https://cyg
I just found this in my spam folder -- along with two other emails you
CCed me on earlier. I'm really sorry for the delay.
Apparently, Google thinks, "You can't speak English, so any English
emails to you must be spam."
2025年7月18日(金) 9:36 Jeremy Drake :
>
> On Sat, 7 Jun 2025, kikairoya via Cygwi
On Sun, Jul 20, 2025 at 12:15:12PM -0600, cygwin wrote:
> On 2025-07-19 22:12, Duncan Roe via Cygwin wrote:
> > Bash's `type` builtin would have told you that. `type` also tells you about
> > aliases and functions, unlike `which` which I haven't used for ages.
>
> Bash's which function tells you mu
On 2025-07-19 22:12, Duncan Roe via Cygwin wrote:
On Sat, Jul 19, 2025 at 01:45:18PM -0400, ... wrote:
I just worked the CMake configuration command
cmake -G"Unix Makefiles"
/cygdrive/C/Users/somia/Downloads/libjpeg-turbo-3.1.1/
and my woes were definitely due to having an msys cmake in my P
I had to get around cygwin and cmake when working with external (
non-cygwin ) cross compilers for the arm.
I found I needed to to some tricks with mount and symbolic links so I
could avoid c:/ paths
I observed that msys type tools would accept /c/ paths and have had success
with the pico-sdk and
Hi Jon,
On Sat, Jul 19, 2025 at 01:45:18PM -0400, cygwin wrote:
> I just worked the CMake configuration command
>
>cmake -G"Unix Makefiles"
> /cygdrive/C/Users/somia/Downloads/libjpeg-turbo-3.1.1/
>
> and my woes were definitely due to having an msys cmake in my PATH. So,
> guys, the guesses t
I wrote:
CMake Error at CMakeLists.txt:107 (math):
math cannot parse the expression: " * 8": syntax error, unexpected
exp_TIMES (2).
-- ERROR-bit build (i386)
-- CMAKE_INSTALL_PREFIX = /opt/libjpeg-turbo
-- CMAKE_INSTALL_BINDIR = bin (/opt/libjpeg-turbo/bin)
-- CMAKE_INSTALL_DATAROOTDIR = (/o
I just worked the CMake configuration command
cmake -G"Unix Makefiles"
/cygdrive/C/Users/somia/Downloads/libjpeg-turbo-3.1.1/
and my woes were definitely due to having an msys cmake in my PATH. So,
guys, the guesses that I was trying with a Windows CMake were close but not
right on. It was *ba
In reply to Brian Inglis, with acknowledgement to Kevin Schnitzius for his
reply also.
There's nothing in my setup that I know of that would account for this odd
behavior. CMake is munging the paths tools in the configuration stage of
its operation. OK, point by point (much detail follows):
On Fri
On Fri, 18 Jul 2025 22:32:01 +0900
Takashi Yano wrote:
> On Fri, 18 Jul 2025 21:31:52 +0900
> Takashi Yano wrote:
> > On Fri, 18 Jul 2025 09:54:20 +0200
> > Corinna Vinschen wrote:
> > > On Jul 18 01:28, Takashi Yano via Cygwin wrote:
> > > > On Fri, 18 Jul 2025 00:44:46 +0900
> > > > Takashi Yano
On 7/18/2025 6:14 PM, Soren via Cygwin wrote:
Hello Cygwinstas,
Cygwin root is C:\ix\cygwin, just so you know.
This is the output I see: mintty screen dump:
$ cmake -G"Unix Makefiles" C:/Users/somia/Downloads/libjpeg-turbo-3.1.1/
Caveat: I'm no expert on cmake, just a long time cygwin user.
On 2025-07-18 16:14, Soren via Cygwin wrote:
Hello Cygwinstas,
Cygwin root is C:\ix\cygwin, just so you know.
This is the output I see: mintty screen dump:
$ cmake -G"Unix Makefiles" C:/Users/somia/Downloads/libjpeg-turbo-3.1.1/
cmake -G"Unix Makefiles" C:/Users/somia/Downloads/libjpeg-turbo-3
On Sat, 19 Jul 2025 00:04:56 +0900
Takashi Yano wrote:
> On Fri, 18 Jul 2025 16:25:49 +0200
> Corinna Vinschen wrote:
> > On Jul 18 22:32, Takashi Yano via Cygwin wrote:
> > > I embedded debug code into mm/cygheap.cc, that is:
> > >
> > > diff --git a/winsup/cygwin/mm/cygheap.cc b/winsup/cygwin/mm
On Fri, 18 Jul 2025 16:25:49 +0200
Corinna Vinschen wrote:
> On Jul 18 22:32, Takashi Yano via Cygwin wrote:
> > I embedded debug code into mm/cygheap.cc, that is:
> >
> > diff --git a/winsup/cygwin/mm/cygheap.cc b/winsup/cygwin/mm/cygheap.cc
> > index 338886468..bab4067e0 100644
> > --- a/winsup/
On Jul 18 22:32, Takashi Yano via Cygwin wrote:
> I embedded debug code into mm/cygheap.cc, that is:
>
> diff --git a/winsup/cygwin/mm/cygheap.cc b/winsup/cygwin/mm/cygheap.cc
> index 338886468..bab4067e0 100644
> --- a/winsup/cygwin/mm/cygheap.cc
> +++ b/winsup/cygwin/mm/cygheap.cc
> @@ -371,7 +3
On Fri, 18 Jul 2025 21:31:52 +0900
Takashi Yano wrote:
> On Fri, 18 Jul 2025 09:54:20 +0200
> Corinna Vinschen wrote:
> > On Jul 18 01:28, Takashi Yano via Cygwin wrote:
> > > On Fri, 18 Jul 2025 00:44:46 +0900
> > > Takashi Yano wrote:
> > > > On Thu, 17 Jul 2025 17:19:49 +0200
> > > > Corinna Vin
On 7/18/25 12:02 AM, Zachary Santer wrote:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/tcgetwinsize.html#tag_17_609
says that if libc has tcgetwinsize(), you only need to get
its declaration.
I've attached the /usr/include/sys/termios.h file included in my MSYS2
installation.
On Fri, 18 Jul 2025 09:54:20 +0200
Corinna Vinschen wrote:
> On Jul 18 01:28, Takashi Yano via Cygwin wrote:
> > On Fri, 18 Jul 2025 00:44:46 +0900
> > Takashi Yano wrote:
> > > On Thu, 17 Jul 2025 17:19:49 +0200
> > > Corinna Vinschen wrote:
> > > > On Jul 17 23:14, Takashi Yano via Cygwin wrote:
On Fri, 18 Jul 2025 17:42:47 +0900
Takashi Yano wrote:
> On Fri, 18 Jul 2025 09:54:20 +0200
> Corinna Vinschen wrote:
> > On Jul 18 01:28, Takashi Yano via Cygwin wrote:
> > > On Fri, 18 Jul 2025 00:44:46 +0900
> > > Takashi Yano wrote:
> > > > On Thu, 17 Jul 2025 17:19:49 +0200
> > > > Corinna Vin
Greetings, Aurélien Couderc!
>> >> Stat and ACL info require additional calls.
>>
>> > Right, but my proposal is to do parallel/async lookups. The Windows NT
>> > kernel depends heavily on multithreading and parallelism, of which
>> > Cygwin uses nothing right now for dir lookups.
>>
>> Not an opt
1 - 100 of 97381 matches
Mail list logo
