From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 885B2BBBB for ; Tue, 21 Feb 2006 03:55:47 +0100 (CET) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k1L2tjWH022872 for ; Tue, 21 Feb 2006 03:55:45 +0100 Received: by wproxy.gmail.com with SMTP id i28so751602wra for ; Mon, 20 Feb 2006 18:55:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=rphR/N25FPVVNCFTIM1tRMMPYLmPGsZBBAjSNbPbMgEORxYbRnmTZ6cZZnyuuZyQCE+f3GnPXZiB1qiZu5j5xo2LI/bZsuXLVmxD1kkDGIYonwpIqumPw9DHTfIabgFc0jkYLSPLwfyhv/+oA4HinGESzODPaQO6TTGHDvUSpR4= Received: by 10.65.188.20 with SMTP id q20mr1125538qbp; Mon, 20 Feb 2006 18:55:44 -0800 (PST) Received: by 10.65.193.14 with HTTP; Mon, 20 Feb 2006 18:55:44 -0800 (PST) Message-ID: <8c64de0a0602201855sb06d640p7c5a9c99d8f061d4@mail.gmail.com> Date: Mon, 20 Feb 2006 21:55:44 -0500 From: "Jeremy Shute" To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Tuareg mode under Cygwin... In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_561_26702911.1140490544174" References: <8c64de0a0602190746x2056a24cke96da953baf76475@mail.gmail.com> <43F9F776.1020006@laposte.net> <43FA1426.7070200@laposte.net> <8c64de0a0602201739p4e6d16f3q24f6ed6dbe47b8a4@mail.gmail.com> X-Miltered: at nez-perce with ID 43FA8131.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 tuareg:01 cygwin:01 mingw:01 cygwin:01 afaik:01 mingw:01 ocamlopt:01 gcc:01 -mno-cygwin:01 mistaken:01 gcc:01 -mno-cygwin:01 compiler:01 compiler:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP autolearn=disabled version=3.0.3 ------=_Part_561_26702911.1140490544174 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > Ok, so that confirms it. > > > I do this because MinGW Caml seems to be using "ar" instructions that > > are meant for the Cygwin version of "ar" (meaning they have an ampersan= d > > preceding the DOS path of the temporary file, which MinGW's "ar" doesn'= t > > understand). > > Huh? Neither does Cygwin's ar, AFAIK. Something may be screwed up with > the MinGW build. ocamlopt -a > It looks to me as if MinGW Caml is actually built with Cygwin, using > > "gcc -mno-cygwin". Maybe I'm mistaken? So, I use MinGW Caml with > > Cygwin. > > "gcc -mno-cygwin" is a MinGW cross-compiler. It does not produce Cygwin > binaries, it does not use Cygwin headers. Yeah, I know. It's the same as the MinGW > compiler, except for the little detail of understanding Cygwin paths to > source and library files. There is no difference between the binaries > produced by Cygwin's "gcc -mno-cygwin" and MinGW's gcc. Actually, there is a difference, but it's very minute. The headers are the same but the compiler structure is different, as far as I remember. A hint as to why that might be: x=3D`which gcc` pushd `dirname "$x"` && nm gcc.exe | grep cygwin && popd That aside, I'm confused. Didn't you just say that you use a native > O'Caml build because the MinGW one is broken? I use the MinGW build from the Cygwin terminal. > Apparently, there is an issue in the ptys. I would say that's an apt > > description. I'll have to try the "ocamlmktop -custom". > > Can you first try to run your version of ocaml in Cygwin's rxvt and let m= e > know if you observe the same problematic behavior? No, the problem is not present in rxvt. Caml pops up as usual. However, C-c in the process will ruin your rxvt, meaning it will escape to the shell but be generally unresponsive to keyboard events AND you can't close the window with the close button in the upper-right. Which I consider a problem. C-c is ingrained (it's like C-w closing my windows, another PITA)= . > I really don't want to use a Cygwin version of Caml. I don't like it > > when projects (Cygwin, Berkeley DB) tell me that I have to license my > > source code a certain way when I link to their libraries. > > AFAIK, Cygwin does not impose any restrictions on the O'Caml bytecode > beyond what the O'Caml license has (unless you use native code, in which > case you do link with Cygwin). Hmmm, interesting. So, O'Caml compiled binaries from Cygwin's O'Caml do no= t use the cygwin DLL for their libc functions? Otherwise, Cygwin simply provides the > toolset, and the O'Caml code is yours. And even in that case, you simply > cannot distribute the *Cygwin* versions of your binaries without > open-sourcing them (since they'd need the Cygwin DLLs to work). And even > that can be worked around, AFAIK, by using the Red Hat buyout license. This "Red Hat buyout license" is news to me, even though I know Redhat bought out Cygwin quite some time ago. I know what is currently said at: http://www.cygwin.com/licensing.html ...could be paraphrased, "Buy the rights to distribute the cygwin1.dll or open your source to everyone you distribute your binaries to." Which means I don't want to link against it, which in turn means that I don't want to develop under that environment and deal with porting incompatible features should I ever want to incorporate my library code in a distributed binary. If there's sufficient interest in helping me add a "-mno-cygwin"-like > option to Cygwin's ocaml (so that it produces MinGW binaries using "gcc > -mno-cygwin"), that would be another alternative for you. Yes, there is interest. Actually, I think the best option is to just fix the problem with the MinGW ar, such that ``ocamlopt -a'' does not barf on the temporary filenames. > I aknowledge and respect their wishes, but I'm also free not to use > > those projects (and therefore, not to contribute my bugfixes and > > experience to their product). > > Indeed. > > > I'm happy to use the shell and the tools, but I want my binaries to be > > unmistakenly mine. > > Well, I'm sorry to say that it is unlikely that Cygwin emacs will ever > work seamlessly with native Windows binaries (e.g., those that spawn a > console unless they detect one -- like ocaml -- since the whole point of > inferior mode in emacs, as I understand it, is to work without a console)= . > By mixing and matching various tools not designed to work together, you > are bound to run into incompatibilities -- this is one of them. Yes, I was wondering if perhaps there was a terminal incantation that would work. I did try ``sh -c ocaml'' with no success. Since this isn't a problem with the Cygwin version of O'Caml (and, FWIW, > you're likely to have the same problem with most Windows console > applications), I'd suggest either requesting this as a Cygwin emacs > feature (on the main Cygwin list) or using a non-Cygwin version of emacs. > At the very least, you'll find a lot more expertise on the main Cygwin > list on how to make Cygwin emacs work with Windows native programs than > you'll find here. Yes, yes. Will do. If you plan to post there, what I said earlier about the problem reporting > guidelines still applies. Thank you! Jeremy ------=_Part_561_26702911.1140490544174 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Ok, so t= hat confirms it.

> I do this because MinGW Caml seems to be using= "ar" instructions that
> are meant for the Cygwin version of "ar" (meaning they h= ave an ampersand
> preceding the DOS path of the temporary file, whic= h MinGW's "ar" doesn't
> understand).

Huh? &nbs= p;Neither does Cygwin's ar, AFAIK.  Something may be screwed up w= ith
the MinGW build.

ocamlopt -a



=
> It looks to = me as if MinGW Caml is actually built with Cygwin, using
> "gcc -mno-cygwin".  Maybe I'm mistaken? &= nbsp;So, I use MinGW Caml with
> Cygwin.

"gcc -mno-cygwin= " is a MinGW cross-compiler.  It does not produce Cygwin
= binaries, it does not use Cygwin headers.

Yeah, I know.

 

It's the same as the MinGW
com= piler, except for the little detail of understanding Cygwin paths to
source and library files.  There is no difference between the= binaries
produced by Cygwin's "gcc -mno-cygwin" and MinGW's g= cc.

Actually, there is a difference, but it's very min= ute.  The headers are the same but the compiler structure is different= , as far as I remember.  A hint as to why that might be:

x=3D`which gcc` pushd `dirname "$x"` && nm = gcc.exe | grep cygwin && popd



That aside, I'm confused.  Didn't you just say that you use a nat= ive
O'Caml build because the MinGW one is broken?

I= use the MinGW build from the Cygwin terminal.



> Apparently, there is an issue in the ptys.  I would say that= 's an apt
> description.  I'll have to try the "ocamlm= ktop -custom".

Can you first try to run your version of ocaml i= n Cygwin's rxvt and let me
know if you observe the same problematic behavior?
No, the problem is not present in rxvt.  Caml pops up as usual. = However, C-c in the process will ruin your rxvt, meaning it will escape to= the shell but be generally unresponsive to keyboard events AND you can't c= lose the window with the close button in the upper-right.  Which I con= sider a problem.  C-c is ingrained (it's like C-w closing my windows, = another PITA).



> I really don't want to use a Cygwin version of Caml.  I= don't like it
> when projects (Cygwin, Berkeley DB) tell me that I have to license= my
> source code a certain way when I link to their libraries.
AFAIK, Cygwin does not impose any restrictions on the O'Caml bytecode
beyond what the O'Caml license has (unless you use native code, in whic= h
case you do link with Cygwin).

Hmmm, interesting.=   So, O'Caml compiled binaries from Cygwin's O'Caml do not use the cyg= win DLL for their libc functions?



 Otherwise, Cygwin simply provides the
toolset, and the O'Caml= code is yours.  And even in that case, you simply
cannot distribute the *Cygwin* versions of your binaries without
ope= n-sourcing them (since they'd need the Cygwin DLLs to work).  And= even
that can be worked around, AFAIK, by using the Red Hat buyout lice= nse.

This "Red Hat buyout license" is news to me, even though= I know Redhat bought out Cygwin quite some time ago.  I know what is = currently said at:

= http://www.cygwin.com/licensing.html

...could be paraphrased, "Buy the rights to distribute the= cygwin1.dll or open your source to everyone you distribute your binaries t= o."  Which means I don't want to link against it, which in turn m= eans that I don't want to develop under that environment and deal with port= ing incompatible features should I ever want to incorporate my library code= in a distributed binary.



If there's sufficient interest in helping me add a "-mno-cygwin&q= uot;-like
option to Cygwin's ocaml (so that it produces MinGW binaries using &quo= t;gcc
-mno-cygwin"), that would be another alternative for you.

Yes, there is interest.  Actually, I think the best = option is to just fix the problem with the MinGW ar, such that ``ocamlopt -= a'' does not barf on the temporary filenames.



> I aknowledge and respect their wishes, but I'm also free not to u= se
> those projects (and therefore, not to contribute my bugfixes and> experience to their product).

Indeed.

> I'm happy t= o use the shell and the tools, but I want my binaries to be
> unmista= kenly mine.

Well, I'm sorry to say that it is unlikely that Cygwin emacs will e= ver
work seamlessly with native Windows binaries (e.g., those that spawn= a
console unless they detect one -- like ocaml -- since the whole point= of
inferior mode in emacs, as I understand it, is to work without a consol= e).
By mixing and matching various tools not designed to work together, = you
are bound to run into incompatibilities -- this is one of them.

Yes, I was wondering if perhaps there was a terminal incantation t= hat would work.  I did try ``sh -c ocaml'' with no success.


Since this isn't a problem with the Cygwin version of O'Caml (and, FWIW,you're likely to have the same problem with most Windows console
applic= ations), I'd suggest either requesting this as a Cygwin emacs
feature (o= n the main Cygwin list) or using a non-Cygwin version of emacs.
At the very least, you'll find a lot more expertise on the main Cygwin<= br>list on how to make Cygwin emacs work with Windows native programs than<= br>you'll find here.

Yes, yes.  Will do.

&= nbsp;

If you plan t= o post there, what I said earlier about the problem reporting
guidelines= still applies.

Thank you!



Jeremy

------=_Part_561_26702911.1140490544174--