|Anonymous | Login | Signup for a new account||2015-08-29 00:19 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006114||OCaml||OCaml general||public||2013-08-01 16:00||2013-08-08 22:28|
|Status||resolved||Resolution||no change required|
|Target Version||Fixed in Version|
|Summary||0006114: ocamlopt -cc "cc" fails when "cc" is a symbolic link|
|Description||In 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?
|Tags||No tags attached.|
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 :
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...
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.
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!
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?
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...
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".
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>.
|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).|
|Thanks for the fixes and the advice. The bug can be closed now.|
|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|