On 28 Nov 2019, at 15:09, Andy Li wrote:
>
> Hi,
>
> The ocaml package is a bit dated.
> The currently packaged version is 4.04.2, released Jun 23, 2017.
> The latest ocaml version is 4.09.0, released Sep 18, 2019.
> It would be great to have it updated.
>
There’s a problem which needs to be
Hi (Yaakov!),
Please could libargon2 be packaged for the two mingw-w64 builds?
I've recently opened https://github.com/P-H-C/phc-winner-argon2/pull/285
which upstreams (and I think corrects) the patches in MSYS2. I also opened
https://github.com/P-H-C/phc-winner-argon2/pull/286 which inclu
I am trying to work out the precise details for character escaping when
starting a Cygwin process from a native (i.e. non-Cygwin) Windows process.
I have an array of command line arguments which I want passed verbatim to
the process, as though it were invoked using execv, with no globbing to take
[With apologies if threading is broken; I erroneously thought as the list was
not subscriber-only that replies would use reply-all and so wasn't subscribed]
On Thu, May 5, 2016 at 06:47 PM, Erik Soderquist wrote:
> On Thu, May 5, 2016 at 11:24 AM, David Allsopp wrote:
> >
> >
Andrey Repin wrote:
> Greetings, David Allsopp!
And greetings to you, too!
> > I'm not using cmd, or any shell for that matter (that's actually the
> > point) - I am in a native Win32 process invoking a Cygwin process
> > directly using the Windows API'
Aaron Digulla wrote:
>
> Am Samstag, 07. Mai 2016 09:45 CEST, "David Allsopp"
> schrieb:
>
>
> > > Then all you need is a rudimentary quoting.
> >
> > Yes, but the question still remains what that rudimentary quoting is -
> i.e.
> > I
Hi!
Peter Rosin wrote:
> I think cygwin emulates posix shell style command line parsing when
> invoked from a Win32 process (like you do). So, try single quotes:
>
> commandLine = "callee.exe \"@\"te\"\n\"st fo@o bar\" \"baz baz '*'
> '\"\\'\"'";
>
> I get this (w/o noglob):
>
> argc = 7
> argv
Marco Atzeri wrote:
>
> Ultimate overview of MS escape howto :
>
> https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/e
> veryone-quotes-command-line-arguments-the-wrong-way/
This is a great article (which I'd not come across before), but this relates
to Microsoft's mechani
Marco Atzeri wrote:
> On 09/05/2016 17:49, David Allsopp wrote:
> > Marco Atzeri wrote:
> >>
> >> Ultimate overview of MS escape howto :
> >>
> >> https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04
> >> /23/e veryone-quotes-c
Aaron Digulla wrote:
> David Allsopp wrote:
> > Aaron Digulla wrote:
> > >
> > > Am Samstag, 07. Mai 2016 09:45 CEST, "David Allsopp"
> > > schrieb:
> > >
> > >
> > > > > Then all you need is a rudimentary quoting.
&g
I've been trying out the x86 emulation in Microsoft's ARM64 version of
Windows 10 1803.
I had two issues with Cygwin x86. The first, which is simple, is that
Windows doesn't by default create C:\Windows\SysWOW64\drivers\etc which
causes /etc/postinstall/base-files-mketc.sh to exit with an error al
Brian Inglis wrote:
> On 2018-07-10 03:51, David Allsopp wrote:
> > I've been trying out the x86 emulation in Microsoft's ARM64 version of
> > Windows 10 1803.
> >
> > I had two issues with Cygwin x86. The first, which is simple, is that
> > Windows do
Corinna Vinschen wrote:
> On Jul 11 00:36, Andrey Repin wrote:
> > Greetings, David Allsopp!
> >
> > > Brian Inglis wrote:
> > >> On 2018-07-10 03:51, David Allsopp wrote:
> > >> > I've been trying out the x86 emulation in Microsoft's A
Corinna Vinschen wrote:
> On Jul 10 10:51, David Allsopp wrote:
> > I've been trying out the x86 emulation in Microsoft's ARM64 version of
> > Windows 10 1803.
> >
> > I had two issues with Cygwin x86. The first, which is simple, is that
> > Windows do
Corinna Vinschen wrote:
> On Jul 12 07:46, David Allsopp wrote:
> > Corinna Vinschen wrote:
> > > On Jul 10 10:51, David Allsopp wrote:
> > > > I've been trying out the x86 emulation in Microsoft's ARM64
> > > > version of Windows 10 1803.
&
David Allsopp wrote:
> Corinna Vinschen wrote:
> > This looks like a bug in the emulator. You may want to contact
> > Microsoft.
>
> Indeed - I can't install the fast ring insider build on this machine
> (driver problem ) but I'm now trying the slow
Marco Atzeri wrote:
> Am 01.09.2018 um 03:24 schrieb Bryan Phelps:
> > Hello,
> >
> >
> > Thank you for all the work on Cygwin! I've been using it to spin up an
> environment to build the OCaml compiler / toolchain, and it was working great.
> >
> >
> > However, today, all our CI builds mysteriousl
Corinna Vinschen wrote:
> On Sep 1 09:56, Andreas Hauptmann wrote:
> > On Sat, 1 Sep 2018 01:24:49 +
> > Bryan Phelps wrote:
> >
> > > I'll continue to look around for a more minimal repro,
> >
> > The normalization of paths with backslashes has changed.
> >
> > The following doesn't work any
cyg Simple wrote:
> On 9/1/2018 5:52 PM, Andrey Repin wrote:
> > Greetings, David Allsopp!
> >
> >>> In terms of this OCAML build system problem:
> >>>
> >>> Please fix your build system. Do not mix POSIX and Win32 paths, use
> >>>
Corinna Vinschen wrote:
> On Sep 1 16:41, David Allsopp wrote:
> > Corinna Vinschen wrote:
> > > Some of the path handling is seriously crippled as soon as you start
> > > using backslashes, and that's a delipberate decision and won't
> > > ch
The dependencies for the opam package in the Cygwin repository are
incomplete. Since setup.ini doesn't support "optional" or "advised"
dependencies (at least I don't think it does), there are choices for how
many dependencies are added, which I leave to the maintainer.
As a minimum, please could l
The dependencies for the ocaml package in the Cygwin repository are
incomplete. ocamlopt depends on the gcc-core and flexdll packages.
More precisely, ocamlopt itself depends on binutils and flexlink. flexlink
requires a C compiler, however it's also possible to use the flexdll package
without spe
Brian Inglis wrote:
> On 2018-01-23 16:36, Steven Penny wrote:
> > On Tue, 23 Jan 2018 14:13:24, Brian Inglis wrote:
> >> I found the following utility works well without elevation - Windows
> >> code from
> >> http://www.leapsecond.com/tools/eject.{c,exe}:
> >>
> >> // eject -- Allow safe removal
Ben via cygwin wrote:
> Assume my CgyWin (on a windows 7) is currently NOT started.
>
> Assume I want to call from Windows my CgyWin and pass a command to
> execute.
>
> Afterwards CygWin should automatically be closed again.
>
> How can I achieve this?
C:\cygwin\bin\bash.exe -c "command"
You
Ben via cygwin wrote:
> When I go to web page
>
> http://cygwin.com/
>
> then I can download CygWin from there (currently the file "setup-
> x86_64.exe").
>
> Unfortunately this file is just an installer which retrieves in turn
> several other files from Internet and remote servers.
>
> Since I
TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by the
0x2 base address requirement added in rebase 4.4.4. Possible fixes
for this at the bottom.
Commit bfd383 in the rebase sources introduces a new minimum base address
requirement of 0x2 for Cygwin64. This is a prob
Corinna Vinschen wrote:
> On Feb 8 11:47, David Allsopp wrote:
> > TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by the
> > 0x2 base address requirement added in rebase 4.4.4. Possible
> > fixes for this at the bottom.
> >
> > Co
Corinna Vinschen wrote:
> On Feb 8 11:47, David Allsopp wrote:
> > TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by the
> > 0x2 base address requirement added in rebase 4.4.4. Possible
> > fixes for this at the bottom.
> > [...]
> > $
Corinna Vinschen wrote:
> On Feb 9 11:29, David Allsopp wrote:
> > Corinna Vinschen wrote:
> > > On Feb 8 11:47, David Allsopp wrote:
> > > > TL;DR flexlink-compiled DLLs (i.e. ocaml libraries) are broken by
> > > > the
> > > > 0x20
Corinna Vinschen wrote:
> On Feb 9 12:40, Corinna Vinschen wrote:
> > On Feb 9 11:29, David Allsopp wrote:
> > > > Apart from that, not only Cygwin DLLs but also the Windows system
> > > > DLLs are all loaded and relocated to the area beyond 0x1:8000,
> &
Corinna Vinschen wrote:
> On Feb 9 13:12, David Allsopp wrote:
> > Corinna Vinschen wrote:
> > > On Feb 9 11:29, David Allsopp wrote:
> > > > [...]
> > > > When this was originally encountered for 64-bit MSVC (this was all
> > > I'm
[reformatted for top-posting]
Lee wrote:
> > -- Forwarded message --
> > From: Jon Turney
> > Date: Fri, 3 Nov 2017 15:26:27 +
> > Subject: Re: Problem running the latest python2-2.7.14-1 under AppVeyor
> > To: The Cygwin Mailing List
> >
> > On 03/11/2017 14:45, Vadim Zeitli
Lee wrote:
> On 3/14/18, David Allsopp wrote:
> > [reformatted for top-posting]
> >
> > Lee wrote:
> >> > -- Forwarded message --
> >> > From: Jon Turney
> >> > Date: Fri, 3 Nov 2017 15:26:27 +
> >>
Is this expected behaviour:
OPAM+DRA@OPAM ~
$ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar ;
touch /tmp/bar/foo ; ls -l /tmp/bar/foo
CYGWIN_NT-6.1-WOW OPAM 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin
0022
-rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo
-rw-rw-r--+
Lee wrote:
> On 3/18/18, David Allsopp wrote:
> > Lee wrote:
> >> On 3/14/18, David Allsopp wrote:
> >> > [reformatted for top-posting]
> >> >
> >> > Lee wrote:
> >> >> > -- Forwarded message --
&
Andrey Repin wrote:
> Greetings, David Allsopp!
>
> > Is this expected behaviour:
>
> > OPAM+DRA@OPAM ~
> > $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar
> > ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM
> >
Ken Brown
> On 3/19/2018 8:48 AM, David Allsopp wrote:
> > Is this expected behaviour:
> >
> > OPAM+DRA@OPAM ~
> > $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar
> > ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM
> >
Ken Brown wrote:
> On 3/21/2018 6:36 AM, David Allsopp wrote:
> > Ken Brown
> >> On 3/19/2018 8:48 AM, David Allsopp wrote:
> >>> Is this expected behaviour:
> >>>
> >>> OPAM+DRA@OPAM ~
> >>> $ uname -a ; umask ; touch /tmp/foo ;
This program fails at the second mmap call with EINVAL:
#include
#include
#include
int main (void) {
void * mem;
/* Reserve 256MB address space for the minor heaps */
mem = mmap(0, 268439552, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (mem == MAP_FAILED)
e
I'm wondering if I may be able to have some pointers for debugging what
seems to be an unexpected interaction between mmap/mprotect/munmap and
malloc with the OCaml runtime.
At the moment, I know that we crash in malloc, so my main question is how to
go further in gdb. I installed the cygwin-debug
On Tue, 18 Oct 2022 at 20:09, Jon Turney wrote:
>
> On 18/10/2022 11:35, David Allsopp wrote:
> > I'm wondering if I may be able to have some pointers for debugging what
> > seems to be an unexpected interaction between mmap/mprotect/munmap and
> > malloc with the
Running Cygwin setup 2.912 with --symlink-type native (or
CYGWIN=winsymlinks:native) is not correctly translating all symlinks. A
default install has these faulty ones:
/etc/pki/tls/cert.pem ->
\??\/etc\pki\ca-trust\extracted\pem\tls-ca-bundle.pem
/etc/pki/tls/certs/ca-bundle.crt ->
\??\/etc\pki\c
Jon Turney wrote:
> On 06/01/2022 10:46, David Allsopp wrote:
> > Running Cygwin setup 2.912 with --symlink-type native (or
> > CYGWIN=winsymlinks:native) is not correctly translating all symlinks.
> > A default install has these faulty ones:
> >
> > /etc/pki/tl
Jon Turney wrote:
> On 06/01/2022 16:45, David Allsopp wrote:
> > Jon Turney wrote:
> >> On 06/01/2022 10:46, David Allsopp wrote:
> >>> Running Cygwin setup 2.912 with --symlink-type native (or
> >>> CYGWIN=winsymlinks:native) is not correctly translating
Jon Turney wrote:
> On 09/01/2022 09:35, David Allsopp wrote:
> > Jon Turney wrote:
> >> On 06/01/2022 16:45, David Allsopp wrote:
> >>> Jon Turney wrote:
> >>>> On 06/01/2022 10:46, David Allsopp wrote:
> >>>>> Running C
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
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 probl
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
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 ve
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.
Th
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 option
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
> > commit
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 code
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) {
> >printf("Zstan
> 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 - it
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
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
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", wh
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
> > >
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 par
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:
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 em
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.
>
If Cygwin's setup requires input (for example, to select a mirror),
with --quiet-mode hidden it simply terminates (there's no apparent
exit status or message, though).
With --quiet-mode noinput, Cygwin setup sits at the appropriate
dialog, but it's of course non-responsive.
Would it be possible i
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 http
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:
> &
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.
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:
> >
[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 in
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 some
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:
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 ***
72 matches
Mail list logo
