Hi Corinna,
> On Apr 9 22:38, Corinna Vinschen via Cygwin wrote:
> > On Apr 3 16:53, David Allsopp via Cygwin wrote:
> > > I have what appears to be a regression in Cygwin 3.5.0 which, owing to
> > > a CI system lagging behind, we've only just discovered.
> >
I have what appears to be a regression in Cygwin 3.5.0 which, owing to
a CI system lagging behind, we've only just discovered.
In order to torture our Unicode support, OCaml's Windows CI compiles
its sources in C:\projects\реализация-mingw64 (that's a directory
under C:\projects with the camel
On Fri, 1 Mar 2024 at 08:03, Takashi Yano via Cygwin wrote:
> Please try: cygwin 3.6.0-0.66.gc77a5689f7bd (TEST)
I can confirm this fixes the issue for me, thank you!
David
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:
On Sat, 3 Feb 2024 at 19:25, Corinna Vinschen wrote:
> > Sorry to say that, but SetThreadErrorMode/CreateProcess don't do what we
> > want them to do. I just tested this myself with a modified Cygwin DLL
> > (code below) and it turns out that the child process error mode is
> > the same as the
On Fri, 2 Feb 2024 at 14:18, Corinna Vinschen via Cygwin wrote:
>
> On Feb 2 13:35, David Allsopp via Cygwin wrote:
> > Jon Turney via Cygwin wrote:
> >
> > > > I'm sympathetic, and personally I would prefer to revert the patch and
> > > >
Jon Turney via Cygwin wrote:
> > I'm sympathetic, and personally I would prefer to revert the patch and
> > stick to SEM_FAILCRITICALERRORS by default.
> >
> > The question is this: Why does, apparently, everybody expect Cygwin to
> > do the "right thing", with different definitions of "right",
On Fri, 2 Feb 2024 at 12:55, Corinna Vinschen via Cygwin wrote:
> On Feb 2 09:43, David Allsopp via Cygwin wrote:
> > On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
> > wrote:
> > >
> > > The behaviour changed in 2020
> > >
> > > https
On Thu, 1 Feb 2024 at 10:02, Corinna Vinschen via Cygwin
wrote:
>
> The behaviour changed in 2020
>
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=21ec498d7f912
>
> not without a discussion
>
> https://cygwin.com/pipermail/cygwin-patches/2020q4/010870.html
Aha, thank you! (congrats
> x86_64-w64-mingw32-gcc produces a Windows program, why Cygwin should
> be involved in the execution ?
I perhaps should have made that crystal clear - in running "./test",
I'm invoking that excecutable _from_ a Cygwin program (in this case
mintty / bash / sh), so Cygwin is very much involved -
On Wed, 31 Jan 2024 at 22:27, Brian Inglis via Cygwin wrote:
>
> On 2024-01-31 06:40, David Allsopp via Cygwin wrote:
> > Starting with this very trivial C program:
> >
> > #include
> > #include
> >
> > int main(void) {
> >
Starting with this very trivial C program:
#include
#include
int main(void) {
printf("Zstandard v%d\n", ZSTD_versionNumber());
}
and compiling with
x86_64-w64-mingw32-gcc -o test.exe test.c -lzstd
when I then run ./test.exe, I get the Windows critical-error-handler
dialog stating "The
Achim Gratz wrote:
> Brian Inglis writes:
> > Problem writing tar (with Cygwin default sys) symlinks before target
> > created under Cygwin 3.5.0 - error messages are issued and tar exits
> > with failure status!
> […]
> > The only likely culprit between 3.4.6 and that commit seems to be
> >
The instructions for building Cygwin changed in April and the FAQ was
updated (c66797ee), but the website doesn't appear to have been regenerated
(https://cygwin.com/faq.html#faq.programming.building-cygwin).
Thanks!
David
--
Problem reports: https://cygwin.com/problems.html
FAQ:
Marco Atzeri wrote:
> On 06.05.2021 02:56, Eliot Moss wrote:
> > Folks - Before I try to Coq mailing lists, I am wondering if anyone
> > here has had success building Coq under Cygwin. I've tried the dune
> > and the make approaches, and both fail, in different ways, but
> > seemingly because
[Continuing second point in
https://cygwin.com/pipermail/cygwin-apps/2021-April/041212.html]
The man-db package prior to 2.9.3-1 on 3 Jan depended on the libiconv
package which, unusually, includes the iconv binary itself.
I noticed as OCaml has assumed since 2017 that iconv would be available
On 03 January 2021 11:17, Achim Gratz wrote:
> Update to version 2.9.3 and cleaning up patches.
>
> Change packaging so that index creation can be triggered by installing the
> man-db-create-index package. Postinstall index update is done in the
> background by default so it won't block setup
Jon Turney wrote:
> On 20/04/2021 15:37, David Allsopp via Cygwin-apps wrote:
> > Attached adds -t/--allow-test-packages to Setup which controls the
> > initial state of the "Test" checkbox.
> >
> > Motivation is to allow one CI cron job to be installing test
Attached adds -t/--allow-test-packages to Setup which controls the initial
state of the "Test" checkbox.
Motivation is to allow one CI cron job to be installing test versions of
packages, then we can help identify things like [1] before they're released.
David
[1]
Jon Turney wrote:
> Handle '--packages package=version' to allow specifing the version of a
> package to install on the command line.
>
> isManuallyWanted() now returns the target packageversion (if specified),
> or an empty packageversion (which is translated into an instruction to
> the solver
Takashi Yano wrote:
> On Fri, 16 Apr 2021 11:17:50 +0100
> David Allsopp wrote:
> > I'm unable to build OCaml using the mingw-w64 compilers with Cygwin
> 3.2.0.
> > Windows 10.0.19042.928 (and tried on three different machines so far)
> >
> > Repro:
> >
> > - Fresh Cygwin64 installation with
Thomas Wolff wrote:
> Am 16.04.2021 um 16:07 schrieb David Allsopp via Cygwin:
> > Thomas Wolff wrote:
> >> Am 16.04.2021 um 12:17 schrieb David Allsopp via Cygwin:
> >>> I'm unable to build OCaml using the mingw-w64 compilers with Cygwin
> >>> 3.2.0.
Thomas Wolff wrote:
> Am 16.04.2021 um 12:17 schrieb David Allsopp via Cygwin:
> > I'm unable to build OCaml using the mingw-w64 compilers with Cygwin
> > 3.2.0. Windows 10.0.19042.928 (and tried on three different machines
> > so far)
> >
> > Repro:
> &
I'm unable to build OCaml using the mingw-w64 compilers with Cygwin 3.2.0.
Windows 10.0.19042.928 (and tried on three different machines so far)
Repro:
- Fresh Cygwin64 installation with make, libiconv, mingw64-x86_64-gcc-core
and git added; fire up mintty
- git clone --depth 1 --recursive
The following packages have been updated in the Cygwin distribution as test:
* flexdll-0.39-1.tar.xz
This is an update to the latest upstream release in advance of OCaml 4.12.0,
which requires it in order to work correctly on x86_64 Cygwin.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
The following packages have been updated in the Cygwin distribution as test:
* flexdll-0.39-1.tar.xz
This is an update to the latest upstream release in advance of OCaml 4.12.0,
which requires it in order to work correctly on x86_64 Cygwin.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
Jon Turney wrote:
> Sent: 01 December 2020 15:21
> To: cygwin-apps@cygwin.com; David Allsopp
> Subject: Re: SSH key for David Allsopp
>
> On 01/12/2020 09:27, David Allsopp via Cygwin-apps wrote:
> >
> > Thanks. I can connect via sftp (or run alive) but I'm getting a
Jon Turney wrote:
> On 30/11/2020 17:30, David Allsopp via Cygwin-apps wrote:
> > Name: David Allsopp
> > BEGIN SSH2 PUBLIC KEY
> > Comment: "Cygwin Packaging Key"
> > C3NzaC1lZDI1NTE5IAExhdEPx3iOcR+dSXb/dByk/3+2+SRSU1UYLqGI11u9
> >
Name: David Allsopp
BEGIN SSH2 PUBLIC KEY
Comment: "Cygwin Packaging Key"
C3NzaC1lZDI1NTE5IAExhdEPx3iOcR+dSXb/dByk/3+2+SRSU1UYLqGI11u9
END SSH2 PUBLIC KEY
OCaml has been partially broken on Cygwin64 since 2018. I did some recent
work upstream to fix it and we're expecting OCaml 4.12.0 by the end of the
year to restore full support.
This requires a new release of flexdll (I also maintain upstream for that).
We could do with an updated FlexDLL
I've been doing some working around the problems with Cygwin 3.1.5+ WSL
junction points in Docker and found three unexpected pieces of behaviour
with CYGWIN=winsymlinks:native
In all cases, these work as expected with the default symlink behaviour
(i.e. CYGWIN unset or without a winsymlinks
Jason Gross wrote:
> I'll try disabling AV and report back, thanks for the advice. The reason
> I'm using 32-bit is because, last I checked (this might have been a year
> or two ago, so my info might be out of date), there were some OCaml or
> opam packages that only worked with 32-bit cygwin.
Andrew Schulman wrote:
> > > There is unfortunately another layer of incompatibility in Unison:
> > > Two Unison executables are only compatible if they were built with
> > > the same version of OCaml.
> >
> > What a mess!
>
> Glad you understand :)
>
> > Would you consider embedding the OCaml
Corinna Vinschen wrote:
> On Jul 10 15:22, David Allsopp via Cygwin-patches wrote:
> > Corinna Vinschen wrote:
> > > On Jul 9 20:30, David Allsopp via Cygwin-patches wrote:
> > > > I have some code where the acl_t returned by get_file_acl is
> > >
Corinna Vinschen wrote:
> On Jul 9 20:30, David Allsopp via Cygwin-patches wrote:
> > I have some code where the acl_t returned by get_file_acl is allocated
> > at 0x80038248. As a result the acl_entry_t generated by acl_get_entry
> > has an "index" of -1, sinc
I have some code where the acl_t returned by get_file_acl is allocated at
0x80038248. As a result the acl_entry_t generated by acl_get_entry has an
"index" of -1, since the pointer was sign-extended to 64-bits.
My fix is trivial and simply casts the pointer to uintptr_t first.
All best,
David
Achim Gratz wrote:
> Brian Inglis writes:
> >>> Cygwin packages are granular and dependencies are functional: which
> >>> of the Cygwin packages opam and opam-installer uses Cygwin package
> >>> ocaml- compiler-libs, or does opam use another ocaml package to build?
>
> >> I don't quite understand
Brian Inglis wrote:
> On 2020-05-28 03:28, David Allsopp via Cygwin wrote:
> > opam assumes that OCaml installed by the "OS" package manager is
> "complete"
> > (i.e. is the same as "make install" from the OCaml sources), which is
> > a p
opam assumes that OCaml installed by the "OS" package manager is "complete"
(i.e. is the same as "make install" from the OCaml sources), which is a
problem when "OS" package managers split upstream ocaml and don't install
the ocaml-compiler-libs package by default.
Please could either the opam or
38 matches
Mail list logo
