Comment author: @lefessan

The problem is not that ocamlopt does not follow symbolic links, it is that it does not see it as a symbolic link. Indeed, in your case, "cc" is a Cygwin symbolic link, while ocamlopt is a native Windows program (mingw), so it cannot access at all the Cygwin hierarchy, unless you provide native Windows paths. This is usually not a problem with relative paths, but you may get the same problem if you try :

ocamlopt /home/user/foo.ml

as ocamlopt won't be able to determine the correct Cygwin root.

I don't think this is an issue with OCaml, but with mixing Cygwin and Mingw programs. Actually, what you need is a Cygwin ocamlopt cross-compiling to Mingw...

Comment author: @protz

I'd be happy to hear about what is broken, since I plan to refresh the installer.

Fabrice, I believe in your example cygwin will perform an automated conversion (with a warning the first time) of a cygwin-style path into a windows-style one.

Comment author: @johnwhitington

Thanks for the clarification.

So here's a summary of what I had to do to get windows OCaml installed on a virgin Windows 7 VM:

1. Untick ActiveTCL - other people have found this isn't working at the moment

2. replace libmoldname.a with libm.a (since the flexdll version in the installer can't cope with empty .a files - this is fixed in flexdll 0.31)

3. Install cygwin and the required packages myself (the OCaml installer's cygwin installer appears to complete, but doesn't actually install much, or put a cygwin terminal on the desktop -- I assume it is failing silently.

4. Rename all the compiler tools from mingw-64-i686-gcc.exe etc to just gcc.exe.

And now it seems to be working.

Thanks for the hard work keeping OCaml windows support working!

Comment author: @protz

Thanks for the information. I have had other reports of the cygwin installer no longer working properly, which is strange, since last time I checked, it did install probably everything. I'll look into it. I also plan to upgrade flexdll.

I don't understand however why you had to rename the gcc executable. Both the verison of OCaml and of Flexdll that I bundle harcode, I believe, the mingw-w64-i686- prefix. Have you figured out who exactly needed an executable called gcc?

Comment author: @johnwhitington

1. I'm using OCamlMakefile which builds the command line

ocamlopt -cc "cc"

for me. I assumed that "cc" would just work -- I'm sure I can tell OCamlmakefile where to find CC, but I'd hoped it would be automatic.

2. When I installed cygwin this morning (from scratch), even typing "gcc" at the command line didn't find the gcc executable. So perhaps it's a cygwin packaging problem in reality...

Comment author: @protz

The naming is intentional. In cygwin, mingw-w64-i686- is a native windows program that compiles native windows programs, while gcc is a cygwin program (found in another package) that compiles cygwin programs, that is, programs that depend on cygwin1.dll. Cygwin packages both, and offers a prefix for the mingw variant.

I think you should tweak your OCamlMakefile to build:

ocamlopt -cc "mingw-w64-i686-gcc" since you are, indeed, using, from the point of view of cygwin, a compiler that is not the "native" one, hence not called "cc".

Comment author: nlucaroni

John, I would strongly suggest using i686-w64-mingw32-gcc instead of shortening it to gcc or cc. In my experience in compiling a large software package on windows with C and external libraries, we had to be very careful in what we were linking in the environment --basically ensuring we were using the i686-w64-mingw32- tools instead of the cygwin tools. This made it clear why errors were occurring. A number of times we would check what shared libraries were required by the executable or what libraries were linked in and noticed cygwin1.dll

replacing libmoldname.a with another library is something I had to do on a 32bit cygwin environment. That is a real problem. Has that been reported anywhere else? It is probably an issue with FlexDLL not being able to link empty library files. On my system the file just contained, <!arch>.

Comment author: @protz

Linking empty files has been fixed in the latest version of flexdll (which is bundled in the "new iteration of the windows installer", per my message on the caml-list).

Comment author: @johnwhitington

Thanks for the fixes and the advice. The bug can be closed now.