From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 6A6E8BC0A for ; Tue, 19 Jun 2007 11:25:34 +0200 (CEST) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [203.16.214.135]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5J9PVQK023101 for ; Tue, 19 Jun 2007 11:25:33 +0200 X-IronPort-AV: E=Sophos;i="4.16,438,1175437800"; d="scan'208";a="104954600" Received: from ppp59-167-2-129.lns1.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.2.129]) by ipmail03.adl2.internode.on.net with ESMTP; 19 Jun 2007 18:55:29 +0930 Subject: Re: [Caml-list] windows ocaml From: skaller To: Christophe TROESTLER Cc: caml-list@inria.fr In-Reply-To: <20070619.092806.212251413.Christophe.Troestler+ocaml@umh.ac.be> References: <1182232242.29571.157.camel@rosella.wigram> <20070619.092806.212251413.Christophe.Troestler+ocaml@umh.ac.be> Content-Type: text/plain Date: Tue, 19 Jun 2007 19:25:26 +1000 Message-Id: <1182245126.32282.17.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4677A10B.004 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 0200,:01 christophe:01 troestler:01 ocamlc:01 bytecode:01 ocamlopt:01 ocamlc:01 camlprog:01 ocamlopt:01 afaik:01 bytecode:01 ocamlrun:01 ocamlrun:01 compiler:01 On Tue, 2007-06-19 at 09:28 +0200, Christophe TROESTLER wrote: > On Tue, 19 Jun 2007, skaller wrote: > > > > on Windows. This is with 3.09 native build. > > Here is what I get for 3.10, MSVC. > > > 1. ocamlc makes a bytecode file without an extension, which > > cannot be executed. Ocamlopt adds '.exe'. This is inconsistent. > > ocamlc without -o produces camlprog.exe We're using -o I believe .. ocamlopt -o fred produces fred.exe not merely fred AFAIK (not on Windows now). This is inconsistent, it broke our build script when we switched from ocamlopt to ocamlc. > > 2. ocamlc makes a bytecode file which, when you add .exe > > to the end can't exec ocamlrun .. even though it is in the PATH. > > ocamlrun filename works fine. > > ocamlc -o a.exe a.ml > > produces a prefectly runnable executable (just typing 'a.exe'). That worked for us too .. if, and only if, the current directory contained ocamlrun.exe. I have no idea why, but there's no question that 3.09 bytecode is NOT looking in the PATH, because ocamlrun filename actually works (where filename is the bytecode file). > > For transparency, the generated bytecode must use the same filename > > (.exe must be added) and the bytecode must actually run. > ^^^^^^^^^^^^^^^^^^ > Isn't it your own choice when you use the -o flag? If that were the case the native code compiler should also not add .exe .. but it does (I think -- not on Windows at the moment). > > It looks like the bytecode is binding the wrong ocamlrun location, > > Maybe you have several ones installed?? There are two, the other one is in Cygwin though, so it shouldn't be involved. Besides 'ocamlrun' as the command found in the PATH actually works. BTW: we're only messing around with bytecode because either Ocamlopt is broken by a stack overflow compiling a dypgen generated grammar (ml file), or dypgen is broken by stack overflow when compiling generating it. It all works on Linux, but fails one way or the other on OSX (ppc), Cygwin, Windows native port, mingw (Cywgin -mnocygwin), and I think OSC (x86). The bytecode compilers generating bytecode seem to handle it on those platforms we've actually managed to get it running on. It's possible some of the problems will go away after Garrigue's quadratic reducing patch to polymorphic variants, since the only real 'bigness' in the dypgen generated file is lots of polymorphic variants, and several functions per constructor .. mostly chained together in a large 'let' binding. Still, can't see why any of that would trash an 8Meg stack. -- John Skaller Felix, successor to C++: http://felix.sf.net