Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006114OCamlOCaml generalpublic2013-08-01 16:002013-08-08 22:28
Reporterjohnwhitington 
Assigned Togasche 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionno change required 
PlatformWindowsOSOS Version
Product Version4.00.1 
Target VersionFixed in Version 
Summary0006114: ocamlopt -cc "cc" fails when "cc" is a symbolic link
DescriptionIn order to get OCaml working on cygwin from protz's installer (which is slightly broken at the moment with respect to the latest cygwin), I had to symbolically link "gcc" and "cc" to the actual implementation, for example to gcc-mingw-w64-i686.exe

So then, ocamlopt -cc "cc" gives "Access denied" because one can't execute a symbolic link. So, I had to actually rename the executables.

Should tools like ocamlopt follow symbolic links when calling external programs, or is that bad style?
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0010064)
lefessan (developer)
2013-08-01 16:29

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...
(0010065)
protz (manager)
2013-08-01 16:32

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.
(0010066)
johnwhitington (reporter)
2013-08-01 16:44
edited on: 2013-08-01 16:44

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!

(0010067)
protz (manager)
2013-08-01 16:59

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?
(0010068)
johnwhitington (reporter)
2013-08-01 17:06

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...
(0010069)
protz (manager)
2013-08-01 17:20

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".
(0010152)
nlucaroni (reporter)
2013-08-08 19:06

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>.
(0010153)
protz (manager)
2013-08-08 20:50

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).
(0010154)
johnwhitington (reporter)
2013-08-08 22:16

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

- Issue History
Date Modified Username Field Change
2013-08-01 16:00 johnwhitington New Issue
2013-08-01 16:29 lefessan Note Added: 0010064
2013-08-01 16:32 protz Note Added: 0010065
2013-08-01 16:44 johnwhitington Note Added: 0010066
2013-08-01 16:44 johnwhitington Note Edited: 0010066 View Revisions
2013-08-01 16:59 protz Note Added: 0010067
2013-08-01 17:06 johnwhitington Note Added: 0010068
2013-08-01 17:20 protz Note Added: 0010069
2013-08-08 19:06 nlucaroni Note Added: 0010152
2013-08-08 20:50 protz Note Added: 0010153
2013-08-08 22:16 johnwhitington Note Added: 0010154
2013-08-08 22:28 gasche Status new => resolved
2013-08-08 22:28 gasche Resolution open => no change required
2013-08-08 22:28 gasche Assigned To => gasche


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker