Aborting Cygwin setup in unattended modes
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 in these situations for Cygwin to abort, preferably with a non-zero exit code? The background to this was running Cygwin setup in GitHub Actions (so UI not visible), _without_ specifying --site, where the Cygwin installation had been restored by actions/cache but not the registry setting in HKLM\SOFTWARE\Cygwin\setup meaning that setup could not find setup.rc and consequently determine the last-used mirror. The GUI therefore invisibly froze at mirror selection. That issue has obviously been fixed, but it would seem sensible that Cygwin's setup doesn't ever display a dialog _requiring_ input where all that input has been disabled! David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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. > > > [...] > > > $ ./t.exe 'C:\Devel\π«ΡΠ΅Π°Π»ΠΈΠ·Π°ΡΠΈΡ-mingw64\flexdll\flexdll_mingw64.o' > > > stat: cannot stat > > > '"C:\Devel\'$'\360\237\220\253''ΡΠ΅Π°Π»ΠΈΠ·Π°ΡΠΈΡ-mingw64\flexdll\flexdll_mingw64.o': > > > No such file or directory > > > > Thanks a lot for the STC! > > > > I think I fixed that for 3.5.4. I pushed a patch and the test release > > cygwin-3.6.0-0.115.g579064bf4d40 is just building and should be ready > > for testing in an hour or two. > > > > Please give it a try. > > Sorry for nagging, but do you have some feedback, be it bad or good? Sorry for having needed nagging! It does indeed fix it, thank you - our smoke-test Bactrian camels can be restored π« All best, David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 emoji U+1F42A followed, I am told, by
the word "implementation" in Russian then with the name of the "port"
of OCaml appended in ASCII).
AppVeyor updated to Cygwin 3.5.1 at the weekend and now, during the
build, we end up with the following kind of error seen in, say,
https://ci.appveyor.com/project/avsm/ocaml/builds/49538801#L711. What
is happening here is that Cygwin's make has passed
C:\projects\π«ΡΠ΅Π°Π»ΠΈΠ·Π°ΡΠΈΡ-mingw64\byte\bin\flexdll_mingw64.o to a
non-Cygwin program (flexlink.exe) which has called back to Cygwin's
x86_64-w64-mingw32-gcc ultimately via CreateProcess and which has then
failed.
I have reduced this chain to the following program, which takes
argv[1] and calls Cygwin's stat program using _wsystem with argv[1]
"-quoted:
#include
#include
int wmain(int argc, wchar_t **argv) {
int len = 2 + 6 + wcslen(argv[1]);
wchar_t *cmd = (wchar_t *)malloc(len * sizeof(wchar_t));
wcscpy(cmd, L"stat ");
cmd[5] = L'"';
cmd[6] = 0;
wcscat(cmd, argv[1]);
cmd[len - 1] = L'"';
cmd[len] = 0;
_wsystem(cmd);
}
Compile with x86_64-w64-mingw32-gcc -municode -DUNICODE -D_UNICODE and
then see it works on Cygwin 3.4.10:
$ ./t.exe 'C:\Devel\π«ΡΠ΅Π°Π»ΠΈΠ·Π°ΡΠΈΡ-mingw64\flexdll\flexdll_mingw64.o'
File: C:\Devel\π«ΡΠ΅Π°Π»ΠΈΠ·Π°ΡΠΈΡ-mingw64\flexdll\flexdll_mingw64.o
Size: 11441 Blocks: 12 IO Block: 65536 regular file
Device: 35525,39577 Inode: 3659174698707368 Links: 1
Access: (0644/-rw-r--r--) Uid: (1049719/ DRA) Gid: (1049089/Domain Users)
Access: 2024-04-03 16:43:36.782037800 +0100
Modify: 2024-04-03 14:09:08.012955600 +0100
Change: 2024-04-03 14:09:08.012955600 +0100
Birth: 2024-04-03 14:09:08.006955500 +0100
but fails on 3.5.1+ (including the latest 3.6.0-0.109 snapshot):
$ ./t.exe 'C:\Devel\π«ΡΠ΅Π°Π»ΠΈΠ·Π°ΡΠΈΡ-mingw64\flexdll\flexdll_mingw64.o'
stat: cannot stat
'"C:\Devel\'$'\360\237\220\253''ΡΠ΅Π°Π»ΠΈΠ·Π°ΡΠΈΡ-mingw64\flexdll\flexdll_mingw64.o':
No such file or directory
Note the stray double-quote at the start of the error. This appears to
be down to the presence of the emoji, rather than the Cyrillic
characters, this is fine in both:
$ ./t.exe 'C:\Devel\ΡΠ΅Π°Π»ΠΈΠ·Π°ΡΠΈΡ\flexdll\flexdll_mingw64.o'
File: C:\Devel\ΡΠ΅Π°Π»ΠΈΠ·Π°ΡΠΈΡ\flexdll\flexdll_mingw64.o
Size: 11441 Blocks: 12 IO Block: 65536 regular file
Device: 35525,39577 Inode: 16607023627376791 Links: 1
Access: (0644/-rw-r--r--) Uid: (1049719/ DRA) Gid: (1049089/Domain Users)
Access: 2024-04-03 16:48:43.003742000 +0100
Modify: 2024-04-03 14:09:08.012955600 +0100
Change: 2024-04-03 16:32:35.648039600 +0100
Birth: 2024-04-03 16:32:35.647539400 +0100
All best,
David
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 parent's process error mode. Changing the thread > > error mode from the Cygwin default 3 (aka SEM_FAILCRITICALERRORS | > > SEM_NOGPFAULTERRORBOX) to 0 doesn't have any effect. > > [...etc.] Oh dear, what a mess! > MSYS2 has introduced the environment variable option CYGWIN=winjitdebug. > I backported this patch now. So default is back to propagating Cygwin's > error mode and if you want to reset the error mode of a non-Cygwin child > process back to OS default, just set the option, for instance, like > this: > > $ CYGWIN=winjitdebug env > > This patch will be in Cygwin 3.5.1. For the time being, it will be > available in the next test release cygwin-3.6.0-0.28.g918c3eda4176 as > well. This completely fixes it for us, thank you very much Thanks, David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 > > > > 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", when in > > > > fact the executable in question can easily call SetErrorMode by itself? > > > > > > Yeah, if cygwin wasn't involved in the process ancestry, how would you > > > get the behaviour you want? > > > > Ah, but that's how I hit this (and started digging further) - > > precisely because the non-Cygwin program I'm using _has_ called > > SetErrorMode and its direct calls to the faulty program _are_ doing > > what's wanted (no popup dialog) but the calls which happen via Cygwin > > are then torching that preference. > > > > Not really suggesting it be done this way (it feels more complicated > > than just reverting the change), but in some ways perhaps Cygwin > > should be using GetErrorMode on startup and instead of not inheriting > > it, ensuring that it sets whatever it received? i.e. just before the > > call to CreateProcess for a non-Cygwin binary, Cygwin restores the > > error mode (for that thread only) to the value read at startup, calls > > CreateProcess and then sets the error mode back. > > This sounds like a good ide, but... > > Is it actually a safe bet that the error mode set by SetThreadErrorMode > is then propagated as process error mode to the child process? > > I have to ask that because Microsoft conveniently forgot to document > this scenario in the MSDN docs. :o) Never knowingly clear, are they! It would seem to be the intent of SetThreadErrorMode that it would behave that way but who knows. Happy to set up a quick experiment to check that it does work (i.e. the invoked process has GetErrorMode set as expected) and that there's no possible race between two threads in the calling process with differing values (i.e. that having SEM_FAILCRITICALERRORS in one thread and not in another behaves as expected. If it does appear to work consistently, would you be willing to go down this route? Happy to do the patch, although it'd be very helpful to have a couple of pointers: I'm guessing the value would want to be captured just before the one place where SetErrorMode is already called, but in which structure should it then be stashed away to be reused in spawn? David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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", when in > > fact the executable in question can easily call SetErrorMode by itself? > > Yeah, if cygwin wasn't involved in the process ancestry, how would you > get the behaviour you want? Ah, but that's how I hit this (and started digging further) - precisely because the non-Cygwin program I'm using _has_ called SetErrorMode and its direct calls to the faulty program _are_ doing what's wanted (no popup dialog) but the calls which happen via Cygwin are then torching that preference. Not really suggesting it be done this way (it feels more complicated than just reverting the change), but in some ways perhaps Cygwin should be using GetErrorMode on startup and instead of not inheriting it, ensuring that it sets whatever it received? i.e. just before the call to CreateProcess for a non-Cygwin binary, Cygwin restores the error mode (for that thread only) to the value read at startup, calls CreateProcess and then sets the error mode back. To explain in the context of the actual call chain: - I have opam.exe (compiled with mingw-w64), which is calling SetErrorMode in main - It's calling ocamlc.exe (in PATH) which requires the zstd DLL, but that has not been put in PATH - A direct call - not via Cygwin - to ocamlc -vnum therefore returns an exit code - Another call, already there from the Unix side, instead does sh -c "ocamlc -config | sed ..." but Cygwin has then _removed_ the calling applications preference Thanks, David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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://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 the 3.5 release, in passing, btw). > > Definitely not a regression, then (subject edited). > > > > However, this patch came from MSYS2, and subsequently they seem to > > have found it problematic for the same reason as me > > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) > > and have just recently reintroduced the flag > > (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) > > to control it. > > > > The reasoning in > > https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as > > valid now as it did in 2006. > > > > Is it possible to revisit having the flag, or even just reverting the > > behaviour? > > > > FWIW, it's been "hurting" us over in OCaml-land since zstd support was > > added roughly a year ago - configure can tell us that mingw-w64's zstd > > is available, but woe betide us if we run the test program to see if > > it actually works, but the user forgot to add the sys-root into PATH, > > because at that point the CI system is down... > > 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", when in > fact the executable in question can easily call SetErrorMode by itself? The executable can't, though (at least, I'm not aware that it can)? The DLL not found case is being triggered by the loader, before the entrypoint code is running? I did have a look to see if there are manifest flags or some such which can be set to indicate this, but it does seem to be the responsibility of the caller, coupled with a "best practice" recommendation on MSDN to call SetErrorMode (as Cygwin is of course doing). The whole system with it feels like unfortunate Windows legacy, but I guess the behaviour vastly predates Event Viewer, etc., and slightly better (and non-blocking) ways of reporting loader errors. Perils of a nearly 40 year old API, if not OS Thanks, David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 on the 3.5 release, in passing, btw). Definitely not a regression, then (subject edited). However, this patch came from MSYS2, and subsequently they seem to have found it problematic for the same reason as me (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624) and have just recently reintroduced the flag (https://github.com/msys2/msys2-runtime/commit/7616b8a2e0ffcf068b47e1a66bbb1dbd7d9b5c50) to control it. The reasoning in https://cygwin.com/pipermail/cygwin/2006-August/150081.html seems as valid now as it did in 2006. Is it possible to revisit having the flag, or even just reverting the behaviour? FWIW, it's been "hurting" us over in OCaml-land since zstd support was added roughly a year ago - configure can tell us that mingw-w64's zstd is available, but woe betide us if we run the test program to see if it actually works, but the user forgot to add the sys-root into PATH, because at that point the CI system is down... Thanks, David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 - it's the caller. In the actual problem which hit this, I have a non-Cygwin executable which has called SetErrorMode(SEM_FAILCRITICALERRORS). If that program calls test, there is no popup displayed. However, it also calls Cygwin's sh and _that_ executes that program too, so something like "C:\cygwin64\bin\sh -c "./test.exe | sed ..." but then the popup error message appears. So somewhere along the line, Cygwin appears to be resetting the system error mode, and that appears contrary to previous (old) messages on the subject. Thanks, David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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) {
> >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 execution cannot proceed because
> > libzstd-1.dll was not found. Reinstalling the program may fix this
> > problem."
> >
> > My question is not how to fix the problem (I'm well aware of that),
> > but rather why that message is being displayed at all, and is it a bug
> > in Cygwin somewhere? All I could find Googling was previous
> > suggestions that Cygwin routinely calls SetErrorMode with, amongst
> > other things, SEM_FAILCRITICALERRORS with the intention of suppressing
> > this dialog.
> >
> > Is that correct, and if so is this just me? :o)
> >
> > Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
> > I also get the same popup if I run C:\cygwin64\bin\sh -c
> > "/cygdrive/c/path/to/test" either from a Command Prompt or even from
> > "Start -> Run". Running this via "sh" called from a non-Cygwin process
> > (itself invoked from a Command Prompt) which has also called
> > SetErrorMode is how I hit this.
>
> Better to let you know that there is a problem, and what the problem is, so
> you
> can fix it!
Thank you, but no - as I made clear by:
> My question is not how to fix the problem (I'm well aware of that)
I'm fully aware what has caused the issue to arise, and how to fix it
- that's not the issue. The problem is that according to previous
messages, and the Cygwin code, my impression was that mintty / bash /
sh (*Cygwin* programs) calling this executable should be returning an
exit code here, not freezing on a message dialog. The problem appears
to be a bug in the Cygwin DLL, and from previous messages on the list,
my question is whether it's a regression, and can be fixed.
The reason it's a problem is, say, a script _in Cygwin_ which is
handed a command to run, runs it, and is then completely blocked by
that popup dialog. It's the responsibility of the _caller_ (a Cygwin
program) to indicate the mode in which a program is executed - the
message box may be owned by the program called, but it's caused by it
being loaded, before it has a chance to run any code.
My understanding, based on this line:
https://github.com/cygwin/cygwin/blob/main/winsup/cygwin/dcrt0.cc#L721
in dll_crt0_0
is that Cygwin executables (in this case mintty / bash / sh, etc.)
should be running with SEM_FAILCRITICALERRORS enabled, following the
best practice recommendations in
https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode
and that that setting should be correctly inherited by processes they
call (including non-Cygwin ones).
Some ancient history, reporting my same issue in 2004:
https://cygwin.com/pipermail/cygwin/2004-March/115553.html and this
thread from 2006
https://cygwin.com/pipermail/cygwin/2006-August/150038.html strongly
indicating that that line dcrt0.cc is there precisely to stop this
popup.
Thanks,
David
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 code execution cannot proceed because
libzstd-1.dll was not found. Reinstalling the program may fix this
problem."
My question is not how to fix the problem (I'm well aware of that),
but rather why that message is being displayed at all, and is it a bug
in Cygwin somewhere? All I could find Googling was previous
suggestions that Cygwin routinely calls SetErrorMode with, amongst
other things, SEM_FAILCRITICALERRORS with the intention of suppressing
this dialog.
Is that correct, and if so is this just me? :o)
Windows 10 22H2, Cygwin 3.4.10, running all the commands from mintty.
I also get the same popup if I run C:\cygwin64\bin\sh -c
"/cygdrive/c/path/to/test" either from a Command Prompt or even from
"Start -> Run". Running this via "sh" called from a non-Cygwin process
(itself invoked from a Command Prompt) which has also called
SetErrorMode is how I hit this.
Thanks!
David
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 > > commit 2023-04-18 fa84aa4dd2fb43eaf7fcdfb040aef854f2f19d01 Cygwin: fix > > errno values set by readlinkat. > > > > Still seems to work as expected despite the error messages and failure > > status. > > > > Runs without any messages or failure under Cygwin stable 3.4.6. > > The interface mentioned above is known to be wonky on various systems. > You might need to re-build tar in oder for it to detect any changed > level of wonkiness and adapt accordingly. On Cygwin 3.4.7, recompiling tar from the source package fixes this problem; the resulting binary then seems to be fine on Cygwin 3.4.6 as well. Please could tar 1.34 be re-packaged? All best, David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 some components can't deal with the uniquenesses of > > Cygwin - though they seem to try to provide for it. > > > > Regards - Eliot > > > > another of those software that thinks Automake/cmake are non needed ... > usually they are a mess to port to un-forecasted platforms. This has nothing to do with the build systems of these packages and everything to do with the fact the ocaml on Cygwin64 has been broken for a while... > $ ./configure >0 [main] ocamlrun 740 child_info_fork::abort: address space needed > by 'dllunix.so' (0x40) is already occupied ... > by 'dllunix.so' (0x40) is already occupied >0 [main] ocamlrun 744 child_info_fork::abort: address space needed > by 'dllunix.so' (0x40) is already occupied I can not automatically > find the name of your architecture. > Give me a name, please [win32 for Win95, Win98 or WinNT]: >^^ frontline technology I see :) Amusingly, the git history shows it has been preserved through updates 13 and 8 years ago, but the line was originally written in 1999. Mature and (formally) proven is possibly the description the Coq team might prefer! > How we solve the reloc issue on 64 bit ? I am a bit ocalm rust I fixed the underlying problem in OCaml 4.12, but I haven't had time to propose adopting the Cygwin packages yet - I'm hoping to over the next few months. The short-term workaround is either to use Cygwin32 or to install the opam, libgmp-devel and flexdll 0.39 packages and run: opam init opam switch -y create coq ocaml-base-compiler.4.12.0 # This takes a looong time, especially the "make install" step opam install -y coq eval $(opam env) coqtop Quit. (NB flexdll 0.39 must be selected manually or using the new flexdll=0.39-1 syntax on the command line, as I've left it marked test until ocaml 4.12 is packaged) HTH, David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 in base, and thus on "any" Cygwin installation. I was already working on removing OCaml's dependency on the iconv binary, so I don't have a strong opinion either way, but should libiconv be put in the Base category in order to keep the installed commands consistent? David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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: > > > > - Fresh Cygwin64 installation with make, libiconv, > > mingw64-x86_64-gcc-core and git added; fire up mintty > > - git clone --depth 1 --recursive https://github.com/ocaml/ocaml > > - cd ocaml && ./configure --host=x86_64-w64-mingw32 && make -j8 > > flexdll && make -j8 world.opt > > > > This is consistently hanging with Cygwin 3.2.0 and seems possibly to > > have something to do with linking (the creation of > > runtime/ocamlrun.exe and stdlib/camlheader, which is also an > > executable, seem to be part of the problem). > > > > It can be immediately fixed by downgrading to Cygwin 3.1.7, cleaning > > the tree and repeating the build. > > > > I'm of course very happy to try to reduce this to a smaller repro > > case, but is there an obvious culprit in Cygwin 3.2.0 to check before I > do? > > Thanks for the report. I looked into this problem and found that the > caused is the combination of some race issues for non-cygwin processes in > pty and console code. > > I will submit the patches fixing this issue. Fantastic, thanks - I'll keep an eye on cygwin-patches and test. David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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. 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 https://github.com/ocaml/ocaml > >>>- cd ocaml && ./configure --host=x86_64-w64-mingw32 && make -j8 > >>> flexdll && make -j8 world.opt > >>> > >>> This is consistently hanging with Cygwin 3.2.0 and seems possibly to > >>> have something to do with linking (the creation of > >>> runtime/ocamlrun.exe and stdlib/camlheader, which is also an > >>> executable, seem to be part of the problem). > >>> > >>> It can be immediately fixed by downgrading to Cygwin 3.1.7, cleaning > >>> the tree and repeating the build. > >>> > >>> I'm of course very happy to try to reduce this to a smaller repro > >>> case, but is there an obvious culprit in Cygwin 3.2.0 to check > >>> before I do? > >> The build fails for me with error messages but it does not hang. > > Thanks for confirming! > > > >> You could have tried at least building without -j option, and running > >> the build steps separately for better diagnostics. > > Indeed - the repro case above was intended to be small and fast. I was > > still at the "is this just me/us", stage. Suggesting a non-parallel > > build of OCaml would have been mean, as it takes about an hour if it > > doesn't crash...! > > > > That said, the non-parallel build I think reveals the Cygwin problem: > > there are console windows constantly flashing up (it renders the > > workstation unusable for the duration of the build). The first stage > > of the build compiles ocamlrun.exe which is non-Cygwin in this case > > and then it uses that throughout the build, so I guess it's the conpty > > changes which are biting. > > > > However, the build did succeed when run without -j, however this > > (which will take about 20 mins or so): > > > > ./configure --build=x86_64-w64-mingw32 --disable-native-compiler make > > flexdll runtop > > > > causes a new console Window to pop up with an OCaml prompt (which can > > be quit by taking #quit;;) rather than the same prompt being connected > > to mintty. > > > > With make -j, it doesn't appear to flash up all the console Windows, > > but it's also reliably failing. I tried with the cygwin1.dll snapshot > > from this morning which seems to be doing the same. > Maybe a non-cygwin tool is injected in your build process? > What if you strip your PATH from all non-cygwin directories? There always has been a non-Cygwin tool - it's calling an ocamlrun.exe it us built at the start of the process with x86_64-w64-mingw32. Is that no longer permitted?! However, I'm not sure how the environment has anything to do with this: everything goes back to working just by downgrading cygwin1.dll to 3.1.7. David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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: > > > > - Fresh Cygwin64 installation with make, libiconv, > > mingw64-x86_64-gcc-core and git added; fire up mintty > > - git clone --depth 1 --recursive https://github.com/ocaml/ocaml > > - cd ocaml && ./configure --host=x86_64-w64-mingw32 && make -j8 > > flexdll && make -j8 world.opt > > > > This is consistently hanging with Cygwin 3.2.0 and seems possibly to > > have something to do with linking (the creation of > > runtime/ocamlrun.exe and stdlib/camlheader, which is also an > > executable, seem to be part of the problem). > > > > It can be immediately fixed by downgrading to Cygwin 3.1.7, cleaning > > the tree and repeating the build. > > > > I'm of course very happy to try to reduce this to a smaller repro > > case, but is there an obvious culprit in Cygwin 3.2.0 to check before I > > do? > The build fails for me with error messages but it does not hang. Thanks for confirming! > You could have tried at least building without -j option, and running the > build steps separately for better diagnostics. Indeed - the repro case above was intended to be small and fast. I was still at the "is this just me/us", stage. Suggesting a non-parallel build of OCaml would have been mean, as it takes about an hour if it doesn't crash...! That said, the non-parallel build I think reveals the Cygwin problem: there are console windows constantly flashing up (it renders the workstation unusable for the duration of the build). The first stage of the build compiles ocamlrun.exe which is non-Cygwin in this case and then it uses that throughout the build, so I guess it's the conpty changes which are biting. However, the build did succeed when run without -j, however this (which will take about 20 mins or so): ./configure --build=x86_64-w64-mingw32 --disable-native-compiler make flexdll runtop causes a new console Window to pop up with an OCaml prompt (which can be quit by taking #quit;;) rather than the same prompt being connected to mintty. With make -j, it doesn't appear to flash up all the console Windows, but it's also reliably failing. I tried with the cygwin1.dll snapshot from this morning which seems to be doing the same. David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 https://github.com/ocaml/ocaml - cd ocaml && ./configure --host=x86_64-w64-mingw32 && make -j8 flexdll && make -j8 world.opt This is consistently hanging with Cygwin 3.2.0 and seems possibly to have something to do with linking (the creation of runtime/ocamlrun.exe and stdlib/camlheader, which is also an executable, seem to be part of the problem). It can be immediately fixed by downgrading to Cygwin 3.1.7, cleaning the tree and repeating the build. I'm of course very happy to try to reduce this to a smaller repro case, but is there an obvious culprit in Cygwin 3.2.0 to check before I do? Many thanks, David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[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 *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: https://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 option). 1. Relative paths get unnecessarily resolved mkdir -p foo/bar cd foo/bar touch baz CYGWIN='winsymlinks:native' ln -s ../bar/baz link readlink link Result is baz, not ../bar/baz 2a. Links in the magic mount directories (/usr/bin and /usr/lib) get extra bits added (source is a default mount): cd /usr/lib CYGWIN='winsymlinks:native' ln -s ../share/terminfo terminfo2 readlink terminfo2 Result is ../usr/share/terminfo, which makes it valid from /lib (the "real" directory) but not in the virtual one 2b. Same but where target is a default mount cd /usr/libexec/p11-kit CYGWIN='winsymlinks:native' ln -s ../../bin/update-ca-trust trust-extract-compat2 readlink trust-extract-compat2 Result is ../../../bin/update-ca-trust, again it seems to be computing an extra level back to the "real" lib directory Are these behaviours expected? I can create those symbolic links manually with mklink with no problem, so I'm wondering if it's an outright bug or an unexpected consequence of something else. Thanks! David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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. This is correct - OCaml has been broken on 64-bit Cygwin for a while, however the forthcoming FlexDLL 0.39 and OCaml 4.12.0 releases (later this year) restore 64-bit support. David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 version in the package name as > > suggested by the Debian maintainer > > (http://lists.seas.upenn.edu/pipermail/unison-hackers/2020- > August/001975.html)? > > Thus unison2.48-2.48.4-1 would be replaced by something like > > unison2.48+4.04.1... and unison2.48-2.48.4-2 would be replace by > > something like unison2.48+4.08.1 That way people who are happy > > with unison2.48-2.48.4-1 can keep using it without being pestered by > setup to update. > > Yes, I could do that. I was hoping to avoid it, but it may be the only > realistic solution. > > It may be mainly Unison 2.48 that's affected, and maybe also 2.51 and the > forthcoming 2.52. I guess that very few people are still using the older > versions, and if they are they don't want any changes now. > > > FWIW, here's my situation, which is probably not typical. When you > > released > > unison2.48-2.48.4-1 a few years ago, it was incompatible with the > > Linux server that I sync with. So I simply built OCaml and unison > > myself on that server, using the same versions that you used, and > > installed unison in my own ~/bin directory. > > > > I could do that again, now using OCaml 4.08.1. But I'd much rather > > just keep my current arrangement, without having setup try to update > > unison2.48 every time I run it. Just for reference, the format of OCaml marshalled values changed in OCaml 4.08 (https://github.com/ocaml/ocaml/pull/1683). It's changed again in OCaml 4.11 as well (https://github.com/ocaml/ocaml/pull/8791) but in that case the new things which OCaml 4.11 can marshal would have caused errors in earlier versions, so I don't think that will affect Unison. Quoting https://caml.inria.fr/pub/docs/manual-ocaml/libref/Marshal.html (emphasis mine): "The format for the byte sequences is compatible across all machines **for a given version of OCaml**" so it's an interesting design choice of Unison's. That said, we (OCaml devs) change the marshal format as infrequently as possible, and go to considerable lengths to ensure that the older format can be read by newer runtimes: IIRC that particular change was the first break since OCaml 4.01 (Sep 2013). David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 your question - opam is OCaml's package > manager. > > The question was if adding ocaml-compiler-libs to the opam requirements is > sufficient or if there are other packages that need to be added as > requirements for opam. A second related question is if any of the > existing ocaml packages are missing dependencies, especially to ocaml- > compiler-libs. Finally, since opam is split into two packages on Cygwin, > which of these needs the requirement. Indeed, adding ocaml-compiler-libs as a dependency of opam is sufficient (opam-installer does not in any way depend on it). The rest of opam's non-build dependencies were dealt with in 2018 (see https://github.com/andyli/opam-cygwin/blame/master/opam.cygport#L22-L23 and the linked https://sourceware.org/legacy-ml/cygwin/2018-01/msg00079.html). > >> It can either compile OCaml itself from sources or use the OCaml > >> installed by the system's package manager. In the second case, it > >> quite reasonably assumes that the OCaml which has been installed is > >> the one the OCaml developers intended which includes its > >> compiler-libs package. Given that opam depends on ocaml, it should > >> also depend on ocaml-compiler-libs, therefore. > > > > What you or the ocaml developers assume does not matter: what matters > > is how the package works. If you do not understand the question and > > can not provide the answer, I can see why the maintainer made his > > choice: he probably never used the packages, just ran any tests > included. > > That sounds unnecessarily harsh to me. It would however be helpful if the > opam maintainer could have a look, since he is undoubtedly much more aware > of the issues on both the OCaml and Cygwin sides than any one of us and > could probably explain why the packages are built the way they are. The dependencies were modified before so that `opam init` succeeds without it being: - install Cygwin's opam package - Run opam init - , re-run Cygwin setup and install a load more Cygwin packages - Run opam init again The additional dependency ensures that the next command many users would then run `opam install ocamlfind` also succeeds. > > It appears that neither ocaml nor opam use ocaml-compiler-libs, > > otherwise the cygwin build and packaging software would include it, so > > which package in the ocaml suite actually binds the > > ocaml-compiler-libs to do its job, or does that package just provide > > dynamic libraries which are expected to be present when anyone runs > ocaml programs? > > In which case users would be expected to manually install the package > > ocaml-compiler-libs. > > It's not uncommon that these captive "package managers" assume a certain > environment without depending directly on it, so you'll indeed have to > manually add the pre-requisites as manual requirements for the Cygwin > package. That doesn't solve the problem that usually language > environments that come with their own package manage don't quite play nice > with the system package manager, especially if the system is not > GNU/Linux. We do our best - the opam developers use a mix of FreeBSD/OpenBSD/macOS/Windows & Debian, so we try to remain accommodating by design :) Thanks, David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 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 ocaml package be updated to depend on > > ocaml-compiler-libs. Fixes > > https://github.com/ocaml/opam-repository/issues/16457. > > > > Debian/Ubuntu and Fedora both also have ocaml-compiler-libs packages, > > but it's installed by their ocaml package as well. > > > > Arch chooses not to do this, having packages like ocaml-findlib > > expressly depending on ocaml-compilerlibs and so also has its opam > > package depend on ocaml-compilerlibs. > > > > As both an upstream OCaml and opam maintainer, I don't mind which > > package has the dependency, but if opam is installed, please can any > > system-installed ocaml definitely be "complete"! > > [current maintainer has resigned so packages are up for adoption] > > 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? > > Current packages are: > emacs-ocaml 4.10.0-1 x86_64 > ocaml 4.10.0-1 x86_64 > ocaml-base 4.10.0-1 x86_64 > ocaml-cairo2 0.6.1-1 x86_64 > ocaml-cairo2-gtk 0.6.1-1 x86_64 > ocaml-cairo2-pango 0.6.1-1 x86_64 > ocaml-calendar 2.04-2 x86_64 > ocaml-camlp4 4.10-0.1 x86_64 > ocaml-camlp5 7.11-1 x86_64 > ocaml-camomile 1.0.2-1 x86_64 > ocaml-camomile-data 1.0.2-1 x86_64 > ocaml-compiler-libs 4.10.0-1 x86_64 > ocaml-cppo 1.6.6-1 x86_64 > ocaml-csv 1.7-1 x86_64 > ocaml-ctypes 0.17.1-1 x86_64 > ocaml-curses 1.0.4-1 x86_64 > ocaml-curses-debuginfo 1.0.4-1 x86_64 > ocaml-debuginfo 4.04.2-1 x86_64 > ocaml-doc 4.10.0-1 x86_64 > ocaml-dune 2.5.1-1 x86_64 > ocaml-extlib 1.7.7-1 x86_64 > ocaml-facile 1.1.3-3 x86_64 > ocaml-fileutils 0.6.2-1 x86_64 > ocaml-findlib 1.8.1-1 x86_64 > ocaml-gettext 0.4.1-1 x86_64 > ocaml-graphics 5.1.0-1 x86_64 > ocaml-gv 2.40.1-5 x86_64 > ocaml-integers 0.3.0-1 x86_64 > ocaml-lablgl 1.06-1 x86_64 > ocaml-lablglade2 2.18.10-1 x86_64 > ocaml-lablgnomecanvas 2.18.10-1 x86_64 > ocaml-lablgnomeui 2.18.10-1 x86_64 > ocaml-lablgtk2 2.18.10-1 x86_64 > ocaml-lablgtk3 3.1.0-1 x86_64 > ocaml-lablgtk3-gtkspell3 3.1.0-1 x86_64 > ocaml-lablgtk3-sourceview3 3.1.0-1 x86_64 > ocaml-lablgtkgl2 2.18.10-1 x86_64 > ocaml-lablgtksourceview2 2.18.10-1 x86_64 ocaml-lablgtkspell 2.18.10-1 > x86_64 ocaml-lablrsvg 2.18.10-1 x86_64 ocaml-labltk 8.06.8-1 x86_64 ocaml- > libvirt 0.6.1.5-1 x86_64 ocaml-libvirt-debuginfo 0.6.1.5-1 x86_64 ocaml- > llvm 8.0.1-1 x86_64 ocaml-llvm-doc 8.0.1-1 x86_64 ocaml-num 1.3-1 x86_64 > ocaml-ocamlbuild 0.14.0-1 x86_64 ocaml-ocamldoc 4.10.0-1 x86_64 ocaml- > ounit 2.2.2-1 x86_64 ocaml-result 1.5-1 x86_64 ocaml-runtime 4.10.0-1 > x86_64 ocaml-source 4.10.0-1 x86_64 ocaml-topkg 1.0.1-1 x86_64 ocaml-xml- > light 2.3-0.2.svn234 x86_64 I don't quite understand your question - opam is OCaml's package manager. It can either compile OCaml itself from sources or use the OCaml installed by the system's package manager. In the second case, it quite reasonably assumes that the OCaml which has been installed is the one the OCaml developers intended which includes its compiler-libs package. Given that opam depends on ocaml, it should also depend on ocaml-compiler-libs, therefore. David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 ocaml package be updated to depend on ocaml-compiler-libs. Fixes https://github.com/ocaml/opam-repository/issues/16457. Debian/Ubuntu and Fedora both also have ocaml-compiler-libs packages, but it's installed by their ocaml package as well. Arch chooses not to do this, having packages like ocaml-findlib expressly depending on ocaml-compilerlibs and so also has its opam package depend on ocaml-compilerlibs. As both an upstream OCaml and opam maintainer, I don't mind which package has the dependency, but if opam is installed, please can any system-installed ocaml definitely be "complete"! Many thanks, David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
