MingW compiler (!) and Ocaml for Windows

MingW compiler (!) and Ocaml for Windows

[Markus E L]

Hi Caml riders,

I'd like to ask wether anybody knows about the status of using the
native Win32 port built with Mingw with the standalone MingW compilers
instead of the Cygwin/MingW compilers.

Until recently my state of awareness was what's been written in
http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32:

   "Do *not* install the Mingw/MSYS development tools from www.mingw.org:
   these are not compatible with this Caml port (@responsefile not
   recognized on the command line)."

Rather accidentally (sourced wrong paths :-) I recently used MinGW
compilers with ocamlopt -- and it worked! I was only partially
suprised, since I've seen patches to MingW gcc floating around
(something like one and a half year ago) that added the
"@responsefile" feature.

Since then I tested a bit more (only with relatively small programs
but also with lablgtk) and it worked for me every time.

Now the question: Would I see the "@responsefile" problem on the first
attempt or are response files only used in certain situations I
perhaps haven't met yet? Can anybody say anything on wether ocamlopt
now works with the MingW compilers (or better wether the MingW
compilers now work with ocamlopt)?

If on the other side problems with "@responsefile" are only occuring
in more rare situation -- can anybody tell me how to provoke the
problem? (Then I'd perhaps be suffieciently interested to try in the
long run to port the missing features from CygWin/MingW to standalone
MingW).

Regards - Markus

PS: I'm using a recent "stable" MingW and the MingW build of ocaml
    3.09.

Re: [Caml-list] MingW compiler (!) and Ocaml for Windows

[Adrien]

Hi,

I've been using ocaml under mingw for some time now and haven't
encountered problems with the compilation and installation of ocaml
(3.09). The vast majority of modules and programs can be compiled and
used directly but of course, some needs modifications which are
usually trivials.
I've had problems with findlib installation which is used for many
modules though. In fact, they're not big deals, just a sum of small
problems : quoting a filename and having proper environment variables
among and a third one I can't remember.

I really want ocaml to run at 100% under mingw (I've had traumatizing
experiences with cygwin ;p ) but I don't have time right now and I
first need to format my computer in order to reorganize the partitions
(moreover I just killed my mingw...).


> If on the other side problems with "@responsefile" are only occuring
> in more rare situation -- can anybody tell me how to provoke the
> problem? (Then I'd perhaps be suffieciently interested to try in the
> long run to port the missing features from CygWin/MingW to standalone
> MingW).

If there's anything I can check, tell me too. =)


---

Adrien Nader

How do I reproduce the problem with @responsfile with ocamlopt and mingw gcc?

[Markus E L]

Hi Caml riders,

Since my last request didn't get any answers or pointers to other
information so far, I'm taking the liberty to repost the central
question with a subject more to the point.

As I already wrote:

http://caml.inria.fr/pub/distrib/ocaml-3.10/notes/README.win32 says:

   "Do *not* install the Mingw/MSYS development tools from www.mingw.org:
   these are not compatible with this Caml port (@responsefile not
   recognized on the command line)."


So there is purportedly a problem using ocamlopt with MingW/MSYS. It
might be that the problem already "went away" in the due progress of
MingW development, or maybe id didn't.

How can I reproduce the problem if it still exists with current
MingW/MSYS? Is trying to ocamlopt-compile a hello_world.ml enough?

Regards -- Markus

PS: Sorry for my impatience. It occured to me that the subject might
    have been misleading since it doesn't show that I really have a
    question to ask.

Re: [Caml-list] MingW compiler (!) and Ocaml for Windows

[Markus E L]

Adrien wrote:

> Hi,
>
> If I can read correctly, diversion is recent (i.e. ocaml 3.10) (
> http://camlcvs.inria.fr/cgi-bin/cvsweb/ocaml/utils/ccomp.ml.diff?r1=text&tr1=1.1&r2=text&tr2=1.20.4.8
> ).

Aha!

>
> For the lazy ones, from ccomp.ml,
>  > if Sys.os_type = "Win32" && String.length s >= 256
>  > then build_diversion lst
>  > else s
> 256 is very low. When compiling ocaml, some commands are more than
> 2100 chars and they don't fail. If there was a 256 character limit I
> wouldn't compile much things (I can make opt.opt for ocaml and
> mldonkey compiles completely).

So you're already using 3.10 on Windows with MingW? Or am I reading
you wrongly?

And does that mean that the supposed problem is/was in the
communication between Ocaml and the MingW compiler? 

>>From this page: http://www.accesspdf.com/article.php/2005020713040824
>  > What about Windows users who use the bash command shell, as packaged by
>  > MSYS? I couldn't find an immediate answer via Google, but I did find a script
>  > that tests this limit. It is used in the libtool configure script.
> I changed it a little,
>  > and the results of my script (below) suggests you have at least 3145729
>  > characters, or about 3MB.
>
>  > This result differs from that cited in the libtool configure script
> comments (256k
>  > character limit for the mingw environment).
>
> I'm sure 256 chars is not the true limit but 256k chars seems too
> high. Conclusion ? =/

Oh no. The matter is completely confused. That is the conclusion. I
think I'll have to do 2 things: Read and grep in the MingW gcc source
and do the same with the last 2 or three ocaml versions. And then try
to set up some test cases. That will take some time, so nobody expect
any results soon :-). My initial hope was that somebody would remember
a clear cut test case and the exact location where the problem is. I'm
also a bit confused by MSYS creeping in here as a topic. 

Perhaps there are two different issues?

The Ocaml-MingW problem can in my estimation only be one of building
the right commandlines for the Mingw-Compiler. Information flow is
from Ocaml to MingW and MingW gcc perhaps must understand
@responsefile. 

The problem between MSYS and Ocaml must be the other way round: MSYS
(shell) calls native Ocaml and when the command line gets too long it
might use @responsefile, so Ocaml needs to understand it.

I thought README.Win32 would refer to the first problem. Which would
have to be fixed in MingW gcc and perhaps already is. But YMMV -- that
is, I'm simply lacking information.

> Btw, I am working on having ocaml work better under mingw. You can
> have a look at this page : http://wiki.cocan.org/ocaml_mingw_port . It
> doesn't work completely but mostly (in fact it may work for ocaml
> 3.09).

That's cool. I think we should pool efforts (well, as many effort as I
can spare at the moment, that is, no promises).

> Having a fully functionnal configure script is required for ocaml
> features not to be determined by the lowest common factor which is
> pretty low under win32...

? Didn't understand that. You're talking about building OCaml under
Win32, not about comoiling with OCaml?

Regards -- Markus

Re: [Caml-list] MingW compiler (!) and Ocaml for Windows

[Leypold Software-Dienstleistungen]

kyra wrote:

> Markus E L wrote:
>> OK. So it seems, @responsefile is only used sometimes, not
>> always. That makes it difficult to see wether the situation actually
>> persists. When was that you got the problem and (if you remember) with
>> which version (approximately at least) of MSYS/MingW). As I said, I'd
>> be interested in the long run to get a distribution of OCaml that is
>> independent of Cygwin and Visual C++.
>
> @responsefile is only used when command-line length exceeds 256 (see
> code in utils/ccomp.ml).
>
> @responsefile idiosyncrasy is a problem of MSYS only (not MinGW).

Then this is probably not the problem from
http://caml.inria.fr/pub/distrib/ocaml-3.09/notes/README.win32 I'm
referring to? I'm a bit confused here, because, AFAI understand, Ocaml
only uses the C-compiler as a backend and that C-Compiler comes from
MingW? So where does MSYS come in?

Or did I get everything wrong and it is OCaml that doesn't understand
the @responsefile generated by MSYS tools?

In this case, can anybody see a reason why it should not be possible
to use the MingW compilers as a backend to OCaml and compile from
CMD.EXE?

Regards -- Markus

Re: [Caml-list] MingW compiler (!) and Ocaml for Windows

[Adrien]

Hi,

If I can read correctly, diversion is recent (i.e. ocaml 3.10) (
http://camlcvs.inria.fr/cgi-bin/cvsweb/ocaml/utils/ccomp.ml.diff?r1=text&tr1=1.1&r2=text&tr2=1.20.4.8
).

For the lazy ones, from ccomp.ml,
 > if Sys.os_type = "Win32" && String.length s >= 256
 > then build_diversion lst
 > else s
256 is very low. When compiling ocaml, some commands are more than
2100 chars and they don't fail. If there was a 256 character limit I
wouldn't compile much things (I can make opt.opt for ocaml and
mldonkey compiles completely).

>From this page: http://www.accesspdf.com/article.php/2005020713040824
 > What about Windows users who use the bash command shell, as packaged by
 > MSYS? I couldn't find an immediate answer via Google, but I did find a script
 > that tests this limit. It is used in the libtool configure script.
I changed it a little,
 > and the results of my script (below) suggests you have at least 3145729
 > characters, or about 3MB.

 > This result differs from that cited in the libtool configure script
comments (256k
 > character limit for the mingw environment).

I'm sure 256 chars is not the true limit but 256k chars seems too
high. Conclusion ? =/


Btw, I am working on having ocaml work better under mingw. You can
have a look at this page : http://wiki.cocan.org/ocaml_mingw_port . It
doesn't work completely but mostly (in fact it may work for ocaml
3.09).
Having a fully functionnal configure script is required for ocaml
features not to be determined by the lowest common factor which is
pretty low under win32...


 ---

Adrien Nader

Re: [Caml-list] MingW compiler (!) and Ocaml for Windows

[kyra]

Markus E L wrote:
> OK. So it seems, @responsefile is only used sometimes, not
> always. That makes it difficult to see wether the situation actually
> persists. When was that you got the problem and (if you remember) with
> which version (approximately at least) of MSYS/MingW). As I said, I'd
> be interested in the long run to get a distribution of OCaml that is
> independent of Cygwin and Visual C++.

@responsefile is only used when command-line length exceeds 256 (see 
code in utils/ccomp.ml).

@responsefile idiosyncrasy is a problem of MSYS only (not MinGW).

Re: [Caml-list] MingW compiler (!) and Ocaml for Windows

[Markus E L]

Dawid Toton wrote:

>  > If on the other side problems with "@responsefile" are only occuring
>  > in more rare situation -- can anybody tell me how to provoke the
>  > problem?
>
> I was compiling an application using LablGTK to native code (using
> MSYS). AFAIR the linker invocation contained quite long list of
> libraries and ocamlopt decided to use responsefile. I got some

OK. So it seems, @responsefile is only used sometimes, not
always. That makes it difficult to see wether the situation actually
persists. When was that you got the problem and (if you remember) with
which version (approximately at least) of MSYS/MingW). As I said, I'd
be interested in the long run to get a distribution of OCaml that is
independent of Cygwin and Visual C++.

> incomprehensible error message (and only then discovered that I have
> to use Cygwin tools). I have no idea whether the problem with MSYS
> tools still persists. When command parameters were short enough they
> worked seamlessly.

:-/ That I feared. 

Regards -- Markus

Re: [Caml-list] MingW compiler (!) and Ocaml for Windows

[Dawid Toton]

 > If on the other side problems with "@responsefile" are only occuring
 > in more rare situation -- can anybody tell me how to provoke the
 > problem?

I was compiling an application using LablGTK to native code (using 
MSYS). AFAIR the linker invocation contained quite long list of 
libraries and ocamlopt decided to use responsefile. I got some 
incomprehensible error message (and only then discovered that I have to 
use Cygwin tools). I have no idea whether the problem with MSYS tools 
still persists. When command parameters were short enough they worked 
seamlessly.

Dawid Toton