Web lists-archives.com

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 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
> >
> 
> Question:
> is libcamlrun.a built correctly and in the same directory than before ?

I haven't double-checked, but the build cannot have got this far if the file were really missing.

> This mixed "../stdlib\libcamlrun.a" slash looks strange

Yeah, our build system is not terribly hygienic when it comes to mixing forward and backslashes in the Windows builds (the Windows shell of course is mostly forgiving of the mixture).

It's not immediately clear to me from the announcement whether this change in behaviour is a regression or an intentional change? Only asking in terms of how quickly we need to make OCaml's build system cleaner.

It's worth noting in this instance that x86_64-w64-mingw32-gcc would be being invoked by a non-Cygwin executable here (i.e. which IIRC is slightly different path normalisation than when it's invoked from bash).


David