[Caml-list] Initial port of ocaml for mingw (long)

[Caml-list] Initial port of ocaml for mingw (long)

[art]

Using code from the cvsnt project (just one function really), I was
able to make an ocaml that does not depend on cygwin1.dll for windows.
The bad news is that currently, it still depends on gcc -mno-cygwin,
sh and make to build programs, etc.  The good news is that it can
produce programs that don't depend on cygwin1.dll as well (from ocamlc
or ocamlopt).  I have tested programs made with both ocamlc and
ocamlopt, and used objdump to verify that they only depend on the
microsoft C runtime.

File needed here:
http://lcc-java.sourceforge.net/ocaml-boot-mingw.tgz
 (New boot directory)
http://lcc-java.sourceforge.net/ocaml-mingw-diffs
 (patch file for ocaml-3.02 distribution for MinGW.

Assumptions:
 (You *must* have the CAMLLIB env variable set to a dos path
  containing your caml libraries.  You have to have libcamlrun.a
  in this directory in order for things to work.  You may wish
  to premake this directory and copy files as necessary)

Building: 

With the files ocaml-3.02.tar.gz, ocaml-mingw-diffs and
ocaml-boot-mingw.tgz in a directory, do the following:
(sorry for breaking the build process)

gzip -d < ocaml-3.02.tar.gz | tar xvf -
cd ocaml-3.02
patch -p 0 < ../ocaml-mingw-diffs
gzip -d < ../ocaml-boot-mingw.tgz | tar xvf -
make
: The build breaks here (access.c) ... builds ok next time
make
: Need some pre-built cmis... not sure why
make	otherlibs/num/int_misc.cmi \
	otherlibs/num/string_misc.cmi \
	otherlibs/num/arith_flags.cmi
make
: Everything except ocamlopt.exe and family made so far
rm byterun/io.h
make -C asmrun depend
make -C byterun depend
: byterun/io.h is replaced by byterun/_io.h due to a name conflict.
make opt
: Everything made
make install 
make installopt
: Installed

Hopefully, this is a step in the right direction for a MinGW port.
In any case, it relives the user of ocaml toplevel environments
from having to have cygwin, in addition to allowing one to create
executables that are free from cygwin.

To complete the cycle, someone who is a bit better with mingw than
I will have to change the compile line in bytelink.ml and asmlink.ml
to reflect mingw, and do new makefiles (perhaps Dmitry will help with
this?)

Art
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

[Caml-list] format types

[Anton Moscal]

Hello!

why 

let _ = List.map printf (["abc\n"; "def\n"]:('a,'b,'c) format list)

work properly, but:

 let _ = List.map printf ["abc\n"; "def\n"]

doesn't compiled with message

 This expression has type ('a, out_channel, unit) format -> 'a
 but is here used with type string -> 'b

I know, O'Caml format type is a hack, but I can't undertand difference 
between thees two expressions for the type inference algorighm.

Regards, 
Anton Moscal
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] format types

[Jacques Garrigue]

> why 
> 
> let _ = List.map printf (["abc\n"; "def\n"]:('a,'b,'c) format list)
> 
> work properly, but:
> 
>  let _ = List.map printf ["abc\n"; "def\n"]
> 
> doesn't compiled with message
> 
>  This expression has type ('a, out_channel, unit) format -> 'a
>  but is here used with type string -> 'b
> 
> I know, O'Caml format type is a hack, but I can't undertand difference 
> between thees two expressions for the type inference algorighm.

You have the answer: this is a hack, and there are no guarantees
anything will type (or have the expected side-effects) if you do not
follow the documentation.

If you understand how the hack works, then you can write the
following (which does not seem very useful):

# let map_printf l = List.map Printf.printf l;;
val map_printf : ('a, out_channel, unit) format list -> 'a list = <fun>
# map_printf ["abc"; "def"];;
abcdef- : unit list = [(); ()]

        Jacques Garrigue
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

[Caml-list] Ocaml 3.03 alpha MinGW port

[Dmitry Bely]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

OK, seems that I've almost completed the native Win32 MinGW port that uses
the same ./configure script and Unix Makefiles (of course updated to
support mingw32 target), so keepeng it in sync should not became the
nigntmare as with MSVC/Mac/... non-unix systems. If it works, maybe to add
it to the stock distribution after some testing? :-)

A special care was taken to not break any existing configuration (no
Gnu make conditional operators etc.), so after applying the patch OCaml
*should* configure and compile on all hosts that were supported before (if
I ocasionally did not break something).

The port supports the same set of libraries as the MSVC one. Both bytecode
and native modes seem to work properly.

Problems
--------

1. Profiling mode (gprof) does not work under MinGW (neither it does under
Cygwin port) - I can enable it in ./configure script, but asmrun/i386.S
does not compile when.

2. I have no idea how to integrate the DLL support. I used Cygwin port as a
template, but it also seems to lack it, although Cygwin/Mingw gcc can build
Win32 DLLs without a problem.

How to use it
-------------

1. Make sure you have the latest Cygwin tools from
http://sources.redhat.com/cygwin. "MinGW runtime" and "w32api" packages are
required.

2. Apply the patch attached to this message.


[-- Attachment #2: diff.bz2 --]
[-- Type: application/octet-stream, Size: 9093 bytes --]

[-- Attachment #3: Type: text/plain, Size: 622 bytes --]


3. Configure OCaml with
  bash -c "./configure -cc 'gcc -mno-cygwin' -host 'i586-pc-mingw32' \
           -tkdefs '-Ic:/Tcl/include' -tklibs '-Lc:/Tcl/lib'" 

Of course paths to tcl/tk may vary. You will also need to create import
libraries from tcl/tk DLLs using impdef/dlltool from the Cygwin
distribution.

If you do not need working labltk, simply omit -tkdefs/-tklibs above.

4. Build and install ocaml as usual:
  make world
  make opt
  make install

It *should* work. At least I was able to rebuld ocaml itself (make bootstrap)
and get working labltk tools (ocamlbrowser etc.)

Hope to hear from you soon,
Dmitry

Re: [Caml-list] Ocaml 3.03 alpha MinGW port

[Masakazu Fukuzawa]

After applying the patch, in ocaml-3.03-alpha\asmcomp\i386\emit.mlp,
add '| "mingw32"' to

  let emit_align =
    match Config.system with
      "linux_elf" | "bsd_elf" | "solaris" | "beos" | "cygwin" ->

to read 

  let emit_align =
    match Config.system with
      "linux_elf" | "bsd_elf" | "solaris" | "beos" | "cygwin" | "mingw32" 
->

and in ocaml-3.03-alpha\asmrun\i386.S, add '|| defined(SYS_mingw32)' to

   || defined(SYS_solaris) || defined(SYS_beos) || defined(SYS_cygwin)

to read 

   || defined(SYS_solaris) || defined(SYS_beos) || defined(SYS_cygwin) |
| defined(SYS_mingw32)

Now you can successfully make opt.opt and use ocamlopt.opt.

Thanks, Dmitry!!

Fukuzawa
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Ocaml 3.03 alpha MinGW port

[Dmitry Bely]

Masakazu Fukuzawa <fukuzawa@cool.email.ne.jp> writes:

> After applying the patch, in ocaml-3.03-alpha\asmcomp\i386\emit.mlp,
> add '| "mingw32"' to

[...]

> Now you can successfully make opt.opt and use ocamlopt.opt.

Oh, sorry. Didn't checked that.

> Thanks, Dmitry!!
> 
> Fukuzawa

You are welcome :-) Everything else works?

Hope to hear from you soon,
Dmitry


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Ocaml 3.03 alpha MinGW port

[Masakazu Fukuzawa]

>
>You are welcome :-) Everything else works?
>

Maybe OK, and I hope so. (You can download
http://caml.inria.fr/Examples/oc/basics/sieve.ml, 
ocamlopt it, and sucessfully run 'sieve 50000',
which previously failed.)

I wish your MinGW port to be incorporated into 
Ocaml 3.03 or above \^_^/


Fukuzawa
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Ocaml 3.03 alpha MinGW port

[Jean-Marc Eber]

There have been some interesting postings on this list
about a MinGW port of the OCaml Compiler. The
attached patch was textually large but conceptually
simple.

I'm really not a specialist about this topic, but have now
(or in a near future) to choose between possible
Windows "technologies" (Visual C, Cygwin, MinGW) for
an OCaml program (only a console mode stuff in my case).

Could anybody explain to me why a MinGW isn't *always*
preferable to a Cygwin one (use of the same compiler, GCC,
MinGW being more "direct" Windows without an indirection
layer, not speaking about licensing problems, etc....).

I understand well that the Caml Team wants probably to
maintain a MS C version of the OCaml implementation,
but wanted to ask the Team if they have some ideas about
the future of Cygwin/MinGW ports. Isn't a MinGW port, in
the medium term, preferable to a Cygwin one ? Or do I
miss a point ?

Jean-Marc Eber
LexiFi



-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Ocaml 3.03 alpha MinGW port

[Xavier Leroy]

> I'm really not a specialist about this topic, but have now
> (or in a near future) to choose between possible
> Windows "technologies" (Visual C, Cygwin, MinGW) for
> an OCaml program (only a console mode stuff in my case).
> 
> Could anybody explain to me why a MinGW isn't *always*
> preferable to a Cygwin one (use of the same compiler, GCC,
> MinGW being more "direct" Windows without an indirection
> layer, not speaking about licensing problems, etc....).

The full Cygwin provides a rather complete Unix emulation, hence the
OCaml Cygwin port supports the debugger, all of the Unix module, and
(I believe) the LablGTK GUI -- all things that are missing in the
OCaml MinGW port, if I remember correctly.

> I understand well that the Caml Team wants probably to
> maintain a MS C version of the OCaml implementation,
> but wanted to ask the Team if they have some ideas about
> the future of Cygwin/MinGW ports. Isn't a MinGW port, in
> the medium term, preferable to a Cygwin one ? Or do I
> miss a point ?

The situation is quite simple, really:

- We can't support three different Windows port of OCaml; the current
  two are already too much.

- Every time I mention this fact on this list, we get replies of the form
    "I can't live without the Visual C based port of OCaml --
     I'm doing real industrial work, and everything gcc-related is
     just amateur work"
  OR
    "I got a Windows machine because that's the company policy,
     but I really do all my work within the Cygwin environment and
     don't want to hear about anything else".

Draw your own conclusions...

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Ocaml 3.03 alpha MinGW port

[Dmitry Bely]

Xavier Leroy <xavier.leroy@inria.fr> writes:

> > I'm really not a specialist about this topic, but have now
> > (or in a near future) to choose between possible
> > Windows "technologies" (Visual C, Cygwin, MinGW) for
> > an OCaml program (only a console mode stuff in my case).
> > 
> > Could anybody explain to me why a MinGW isn't *always*
> > preferable to a Cygwin one (use of the same compiler, GCC,
> > MinGW being more "direct" Windows without an indirection
> > layer, not speaking about licensing problems, etc....).
> 
> The full Cygwin provides a rather complete Unix emulation, hence the
> OCaml Cygwin port supports the debugger, all of the Unix module,

Yes, MinGW port lacks that (as well as MSVC one -- that's Win32 without
fork() and other stuff). MSVC and MinGW ports support absolutely the same
set of OCaml libraries.

> and
> (I believe) the LablGTK GUI -- all things that are missing in the
> OCaml MinGW port, if I remember correctly.

Hmm, IIRC standard 3.03 alpha contains only LablTk, not LablGTK. Yes, with
MinGW patch LablTk can be compiled out of the box. As for LablGTK, it
also should not be a problem -- gtk/Win32 does not rely on Cygwin...

> > I understand well that the Caml Team wants probably to
> > maintain a MS C version of the OCaml implementation,
> > but wanted to ask the Team if they have some ideas about
> > the future of Cygwin/MinGW ports. Isn't a MinGW port, in
> > the medium term, preferable to a Cygwin one ? Or do I
> > miss a point ?
> 
> The situation is quite simple, really:
> 
> - We can't support three different Windows port of OCaml; the current
>   two are already too much.

MinGW port in fact do not need any extra support; it uses the same
sources as MSVC one (and even links with MS-supplied C runtime library
msvcrt.dll), and shares Make/Configure environment with all other Unixes. I
see no real problem here...

> - Every time I mention this fact on this list, we get replies of the form
>     "I can't live without the Visual C based port of OCaml --
>      I'm doing real industrial work, and everything gcc-related is
>      just amateur work"
>   OR
>     "I got a Windows machine because that's the company policy,
>      but I really do all my work within the Cygwin environment and
>      don't want to hear about anything else".
> 
> Draw your own conclusions...

OK, I do not insist. It really may not worth your efforts. I just thought
that for people, who cannot/does not want to buy expensive and
multimegabyte MSVC but need C compiler under Win32 (for custom runtimes,
CamlIDL etc), native Win32 port of OCaml, compiled with gcc compiler, would
be very convenient...

Hope to hear from you soon,
Dmitry


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr