From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA18265; Tue, 10 Apr 2001 10:48:44 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA18261 for ; Tue, 10 Apr 2001 10:48:43 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f3A8mdb16932; Tue, 10 Apr 2001 10:48:39 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA18257; Tue, 10 Apr 2001 10:48:39 +0200 (MET DST) Date: Tue, 10 Apr 2001 10:48:39 +0200 From: Xavier Leroy To: Chris Hecker Cc: caml-list@inria.fr Subject: Re: [Caml-list] minor suggestions for Win32 port Message-ID: <20010410104839.B16732@pauillac.inria.fr> References: <200104070314.UAA24087@smtp4-cm.mail.eni.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200104070314.UAA24087@smtp4-cm.mail.eni.net>; from checker@d6.com on Fri, Apr 06, 2001 at 08:14:42PM -0700 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 1. If you're using the MSVC cl.exe compiler, it sends linker command > line parameters in a relatively broken way, so this affects the > -cclib switch. I can't say I fully understand all the issues, but if you can sort them out and send me a patch, I'll be very happy. Concerning Lionel Fourquaux's suggestion of calling link.exe directly, this can also be considered, although for "ocamlc -custom" we also need to call the C compiler to compile a small chunk of generated C code. > 2. Win9x, pile of dung that it is, has rather strict command line > length limitations. Since ocaml tries to pass all the objs and > whatnot on the command line for the final link, it fails with big > projects on Win9x. The solution to this is to use a "response > file". A response file is a tmp file you write out with all the > parms, and then call the compiler like this: "cl.exe > @/tmp/rsp.tmp" and it reads the response file as if it was a > command line. The Sys.command OCaml function knows how to use a response file if the command-line is too long (see byterun/win32.c, function win32_system()). However, it is calibrated for Win NT/2K, where the maximal length of a command line is circa 1000 characters. I can reduce the maximal length to what Win9x tolerates, although the best solution would be to find out at run-time the max length that the system tolerates. (Going through response files when not absolutely necessary is a bit of a problem, since the command that we're calling might not understand response files, so better avoid them if at all possible.) Any ideas on how to do this in Win32? > 3. [...] I > finally tracked it down to the fact that the boot/ocamlc file in > the tarball was compiled on Linux (or at least with the cygwin > stuff), so its rules for adding object files and linking -custom > bytecode apps are incompatible with VC (namely, it looks for .o > files, not .objs, and it tries to spawn gcc rather than link.exe > or cl.exe). Once I figured this out I was able to build by > putting a VC ocamlc into boot/. Right, currently the source distribution contains just a Unix boostrap compiler, which (barely) suffices to bring the system up to speed even under Win32. To address the problem you had, it should be enough to do "nmake -f Makefile.nt bootstrap", which completes the bootstrap so that the boot compilers and the generated compilers are identical (and Win32-aware). > 4. Have the makefile.nt put the .exe extension on all the output > files. I must have missed a few .exe extensions. Again, if you happen to have patches handy... Cheers, - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr