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

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

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

[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

[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

[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

[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

[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