Ocaml 4.07.1 and 4.08.1 no longer build after Cygwin Update

[MSoegtropIMC]

After an update of the Cygwin supplied MinGW headers, neither OCaml 4.07.1 nor OCaml 4.08.1 build any more. The root cause is that function snprintf was not defined and emulated before and is now defined which interfers with the emulation.

I attached a patch for 4.07.1 and 4.08.1 - I didn

I didn't do a PR since I don't fully underastand the way in which you supply patch files - I would just put them into the files folder but the existing opam files use a different process.

Also note that the patch is not terribly elegant - it keeps the emulation and just works around the issue. It would be better to detect the availability of the function. This patch should work with old and new Cygwin, though.

patches.zip

[dra27]

Alternate fix at https://github.com/ocaml/ocaml/pull/9939

[fdopen]

Thanks, I've applied your patch in 2aaaee7

[MSoegtropIMC]

@fdopen: may I ask why you put the patches into separate gists rather than putting them in a files subfolder besides the opam file? The latter would be much easier to review and maintain. I would say this method is fairly uncommon and I would like to understand the reason why you are doing it like this.

[fdopen]

Historic reasons, compiler packages and normal packages originally had different formats. Compiler packages only supported external patches, and normal packages had their patches under 'files/'. I kept this structure out of laziness (less changes where necessary for my scripts).

It also has advantages:

• the patches can be easily shared across different packages, e.g. ocaml-variants.4.09.1+msvc64 and ocaml-variants.4.09.0+mingw32 link to the same patch. (Otherwise the same patches would have to be stored at 12 different locations.)
• the repo remains smaller. You only need to download a patch, if you want to compile the corresponding package.

[MSoegtropIMC]

I see - thanks for the details!

The main downside I see that I can't see in github what has been changed on the patches - for that I have to download the old and new version of the patch and diff them locally.

[fdopen]

The update also has another side effect: dlls (like dllcamlstr.dll) now seem to always depend on libgcc_s_sjlj-1.dll, unless -static-libgcc is passed to the linker (32bit only). This already breaks "make world.opt" for some OCaml versions, if libgcc_s_sjlj-1.dll isn't inside $PATH (e.g. cygwin's default $PATH).

[MSoegtropIMC]

This already breaks "make world.opt" for some OCaml versions, if libgcc_s_sjlj-1.dll isn't inside $PATH (e.g. cygwin's default $PATH).

I think if one builds for MinGW cross under Cygwin one should have the proper MinGW binary folder in the path. My Coq build scripts - which also create a dedicated cygwin - set the following path (in the user profile):

export PATH=/usr/local/bin:/usr/bin:/usr/$TARGET_ARCH/sys-root/mingw/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows"

I would prefer the DLL variant and would suggest that it is just documented that the path has to be like this for using the MinGW cross opam. Maybe it would also make sense to offer a batch file to setup a dedicated cygwin. Mine is here: (https://github.com/coq/platform/blob/master/coq_platform_make_windows.bat) and (https://github.com/coq/platform/blob/master/windows/configure_profile.sh). These scripts are CC0, please feel free to copy / modify them.

Btw.: using the Cygwin default path leads to errors for many users because it is too long. I also do this:

unset ORIGINAL_PATH
unset OCAMLLIB

the first to reduce the environment size (together with setting PATH to something small), the latter to avoid conflicts with OCaml installed by the Windows OCaml installer. With that I get fairly few error reports.