Re: Bug Report: Regression in Cygwin 2.11.0-1

[Bryan Phelps]

> As for the bug in question:  I pushed a patch which should fix this 
> issue.  I created new developer snapshots and uploaded them to 
> https://cygwin.com/snapshots/.  Please give them a try. 

Thank you Corinna for the quick fix and investigation!

I set up an environment to test it out: 
https://github.com/bryphe/test-ocaml-build and ran a build against the patched 
dll.
It looks like the patch fixes our scenario - the build is green with the 
patched dll: https://ci.appveyor.com/project/bryphe/test-ocaml-build, so the 
patch fixes our problem.

> On the other hand, those that will find problems, the people building
packages, will only do that on "official" releases.

I'm pretty new to the Cygwin ecosystem - we could certainly create nightly 
builds that test against cygwin releases, if that helps (and adjust our CLI 
script to grab the nightly / latest test release of Cygwin).

I wonder if, for a change like this, we could add a test case that exercises it 
- looking through the source, it looks like cygload.cc has a few test cases 
around pathing - perhaps it would be helpful to add a regression test for the 
minimal repro?

Thanks again for the help and investigation!
Bryan
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Bug Report: Regression in Cygwin 2.11.0-1

[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 mysteriously started failing - at first, I 
suspected it was a problem with AppVeyor, but I also failures with VSTS. We use 
an NPM package (`esy-bash`) to spin up a Cygwin environment, and then use that 
to build the OCaml toolchain.


The error message we started receiving today is:

OCAML_FLEXLINK="../boot/ocamlrun ../flexdll/flexlink.exe" ../byterun/ocamlrun 
../ocamlc -g -nostdlib -I ../utils -I ../parsing -I ../stdlib -I 
../compilerlibs -strict-sequence -safe-string -strict-formats -w 
+a-4-9-41-42-44-45-48 -warn-error A -custom ocamlcommon.cma -o ocamltest.exe 
run_win32.o run_stubs.o ocamltest_config.cmo testlib.cmo run_command.cmo 
filetype.cmo filecompare.cmo backends.cmo variables.cmo environments.cmo 
builtin_variables.cmo builtin_modifiers.cmo actions.cmo builtin_actions.cmo 
tests.cmo builtin_tests.cmo tsl_ast.cmo tsl_parser.cmo tsl_lexer.cmo 
tsl_semantics.cmo options.cmo main.cmo
x86_64-w64-mingw32-gcc: error: ../stdlib\libcamlrun.a: No such file or directory


The complete build log is here:

https://gist.github.com/bryphe/58603ab752ecd988f78ee383fa9c9e78


After some investigation, I was able to isolate the issue - environments with 
the 2.10.0-1 version of Cygwin built successfully, whereas newer environments 
with the 2.11.0-1 version exhibit this failure. The remaining packages are in 
parity - importantly, all the mingw packages we install are at the same version.


Results of cygcheck -c on both environments:

- Working environment: 
https://gist.github.com/bryphe/b11f72f60d9d7c04a8e709e6a8eb20ff

- Failing environment: 
https://gist.github.com/bryphe/7cf4e6216030781eb273ac45d36590cd


I'll continue to look around for a more minimal repro, but I suspect there may 
be other manifestations of it. It looks like there were a few path-related 
patches that came in to 2.11.0-1, so perhaps this scenario was impacted.


In the meantime - is there a way we can pin the cygwin package to the 2.10.0-1 
version, to unblock our builds?


Thank you!

Bryan



Sent from Outlook

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple