Re: 3.5.x regression: misquoting command line arguments from native processes

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. > >

3.5.x regression: misquoting command line arguments from native processes

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

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

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:

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

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

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

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 > > > >

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

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",

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

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

Re: Restore SEM_FAILCRITICALERRORS [was: Aren't Windows System Error popups meant to be disabled in Cygwin?]

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

Re: Aren't Windows System Error popups meant to be disabled in Cygwin?

> 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 -

Re: Aren't Windows System Error popups meant to be disabled in Cygwin?

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) { > >

Aren't Windows System Error popups meant to be disabled in Cygwin?

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

Re: Cygwin test 3.5.0 tar symlinks error messages and failure status

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 > >

Re: Debugging malloc crash in gdb

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 > > mallo

Debugging malloc crash in gdb

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

RE: [ITA] ocaml 4.14.0

Corinna Vinschen wrote: > On Aug 23 20:00, David Allsopp wrote: > > Jon Turney wrote: > > > I'm confused here: /usr/lib/ocaml/camlheaderd[di] look like > > > executables (according to file etc.) > > > > > > If they genuinely aren't, then perhaps they s

RE: [ITA] ocaml 4.14.0

Jon Turney wrote: > On 13/07/2022 16:41, David Allsopp wrote: > > > >> 3) Interesting - on my machine, the camlheader[di] files had the .exe > >> extensions. I did some digging around and found the files are *built* > >> without the .exe suffix, an

RE: [ITA] ocaml 4.14.0

William Hu wrote: > Hi David, > > > What were the missing symbols? With the OCaml 4.10 package, I hit > problems with this: > > > > echo 'print_endline "hello, world"' > hello.ml > > > > ocamlc -custom -runtime-variant _shared -o hello.exe hello.ml > > > > I think that may be an issue upstream

RE: [ITA] ocaml 4.14.0

> 1) libcamlrun: Oops, that's another oversight, forgot to look at the old > patches. The other 3 patches seem unnecessary, but I had trouble linking > either libcamlrun_shared.so or libcamlrun_shared.dll.a into a program > (unresolved symbol errors). Added but it possibly needs further patching.

mmap failing with MAP_FIXED

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)

RE: Cygwin setup writing incorrect symlinks for native

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

RE: Cygwin setup writing incorrect symlinks for native

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

RE: Cygwin setup writing incorrect symlinks for native

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

Cygwin setup writing incorrect symlinks for native

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 ->

RE: Fix nanosleep returning negative rem

> On Jul 20 16:16, David Allsopp wrote: > > I've pushed a repro case for this to > > https://github.com/dra27/cygwin-nanosleep-bug.git > > > > Originally noticed as the main CI system for OCaml has been failing > > sporadically for the signal.ml test mentioned

Fix nanosleep returning negative rem

I've pushed a repro case for this to https://github.com/dra27/cygwin-nanosleep-bug.git Originally noticed as the main CI system for OCaml has been failing sporadically for the signal.ml test mentioned in that repo. This morning I tried hammering that test on my dev machine and discovered that it

Regenerate Cygwin FAQ

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:

RE: Building Coq in Cygwin

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

Cygwin base install no longer has iconv binary

[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

RE: [ITA] man-db

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

RE: [PATCH setup] Add --allow-test-versions

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

[PATCH setup] Add --allow-test-versions

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]

RE: [PATCH setup] Handle '--packages package=version'

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

RE: [PATCH 0/2] Fix race issues.

Corinna Vinschen wrote: > On Apr 19 19:30, Takashi Yano wrote: > > Takashi Yano (2): > > Cygwin: console: Fix race issue regarding cons_master_thread(). > > Cygwin: pty: Fix race issue in inheritance of pseudo console. > > > > winsup/cygwin/fhandler_console.cc | 10 ++- > >

RE: Regression in Cygwin 3.2.0

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: > > >

RE: Regression in Cygwin 3.2.0

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.

RE: Regression in 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: > &

Regression in Cygwin 3.2.0

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

[ANNOUNCEMENT] Updated: flexdll 0.39-1 (TEST)

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 ***

Updated: flexdll 0.39-1 (TEST)

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 ***

RE: SSH key for David Allsopp

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

RE: SSH key for David Allsopp

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 > >

SSH key for David Allsopp

Name: David Allsopp BEGIN SSH2 PUBLIC KEY Comment: "Cygwin Packaging Key" C3NzaC1lZDI1NTE5IAExhdEPx3iOcR+dSXb/dByk/3+2+SRSU1UYLqGI11u9 END SSH2 PUBLIC KEY

[ITA] flexdll

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

Strange behaviour with winsymlinks:native

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

RE: Debugging Crash of setup-x86.exe?

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.

RE: [ANNOUNCEMENT] unison2.48-2.48.4-2 (Warning: possible breakage)

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

RE: [PATCH] Fix incorrect sign-extension of pointer in 32-bit acl __to_entry

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 > > >

RE: [PATCH] Fix incorrect sign-extension of pointer in 32-bit acl __to_entry

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

[PATCH] Fix incorrect sign-extension of pointer in 32-bit acl __to_entry

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

RE: opam package should depend on ocaml-compiler-libs

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

RE: opam package should depend on ocaml-compiler-libs

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 package should depend on ocaml-compiler-libs

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

Packaging request: mingw-w64 versions of libargon2

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

Re: Any chance of updating the ocaml package?

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

RE: Bug Report: Regression in Cygwin 2.11.0-1

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 > > > change, even

RE: Bug Report: Regression in Cygwin 2.11.0-1

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 > >>&

RE: Bug Report: Regression in Cygwin 2.11.0-1

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

RE: Bug Report: Regression in Cygwin 2.11.0-1

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

RE: Cygwin x86 on Windows 10 ARM64

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 ring inste

RE: Cygwin x86 on Windows 10 ARM64

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. > &

RE: Cygwin x86 on Windows 10 ARM64

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 doesn't by d

RE: Cygwin x86 on Windows 10 ARM64

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 ARM64 >

RE: Cygwin x86 on Windows 10 ARM64

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 doesn't by d

Cygwin x86 on Windows 10 ARM64

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

RE: umask not working?

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 ;

RE: umask not working?

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 > >

RE: umask not working?

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 > >

RE: setup -g ???

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 -- &

umask not working?

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

RE: setup -g ???

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 + > >>

RE: setup -g ???

[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

RE: Regression for OCaml introduced by rebase 4.4.4

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

RE: Regression for OCaml introduced by rebase 4.4.4

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, > &

RE: Regression for OCaml introduced by rebase 4.4.4

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

RE: Regression for OCaml introduced by rebase 4.4.4

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. > > [...] > > $

RE: Regression for OCaml introduced by rebase 4.4.4

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

Regression for OCaml introduced by rebase 4.4.4

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

RE: Searching full, portable Cygwin package for windows and NOT just the installer

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

RE: How to start Cygwin from outside Cygwin and pass a command to execute?

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"

RE: Ejecting a USB drive using Cygwin (sync)?

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

Missing dependencies for opam package

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

Missing dependencies for ocaml package

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

RE: [PATCH] Preserve order of dlopen'd modules in dll_list::topsort

Hi Corinna, Thanks for the feedback! Corinna Vinschen wrote: > Hi David, > > thanks for the new patch. > > On Feb 27 17:13, David Allsopp wrote: > > Corinna Vinschen wrote: > > > On Feb 25 16:27, David Allsopp wrote: > > > > This patch (below -

RE: [PATCH] Preserve order of dlopen'd modules in dll_list::topsort

Hi Corinna, Corinna Vinschen wrote: > Hi David, > > On Feb 25 16:27, David Allsopp wrote: > > This patch (below - I hope I have managed to format this email > > correctly) alters the behaviour of dll_list::topsort to preserve the > > order of dlopen'd units. > >

RE: Formatting command line arguments when starting a Cygwin process from a native process

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

RE: Formatting command line arguments when starting a Cygwin process from a native process

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

RE: Formatting command line arguments when starting a Cygwin process from a native process

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

RE: Formatting command line arguments when starting a Cygwin process from a native process

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 >

RE: Formatting command line arguments when starting a Cygwin process from a native process

Aaron Digulla wrote: > > Am Samstag, 07. Mai 2016 09:45 CEST, "David Allsopp" <dr...@cantab.net> > schrieb: > > > > > Then all you need is a rudimentary quoting. > > > > Yes, but the question still remains what that rudimentary quoting is - &

RE: Formatting command line arguments when starting a Cygwin process from a native process

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's CreateProces

RE: Formatting command line arguments when starting a Cygwin process from a native process

[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: > > > > I am

Formatting command line arguments when starting a Cygwin process from a native process

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