Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Jon Leichter" To: , Cc: , Subject: RE: Compiling apps to Mingw32 with cygwin Date: Fri, 11 Jan 2002 10:32:13 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C3ED3F6.9DD9A87C@yahoo.com> > -----Original Message----- > From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com]On Behalf > Of Earnie Boyd > Sent: Friday, January 11, 2002 4:01 AM > To: Jon Leichter > Cc: hschwentner AT yahoo DOT com; cygwin AT cygwin DOT com > Subject: Re: Compiling apps to Mingw32 with cygwin > > Jon Leichter wrote: > > > > The key to our lack of agreement is terminology, perhaps due > > to me. I understand that the -mno-cygwin switch causes > > Cygwin-GCC to generate MinGW Cygwin-GCC is still a Cygwin > > binary. All other tools are still Cygwin binaries. I am > > not so sure that warrants the phrase "MinGW build > > environment". It seems to me that I'm still using > > a Cygwin build environment to generate MinGW binaries. > > Not in the sense of what the "build environment" means to > AC_CANONICAL_SYSTEM, in those terms you are switching the build > environment. If you were using a true cross build system for MinGW > then, yes you would be correct. Since `gcc -mno-cygwin' isn't a true > cross build system then you're not correct. The -mno-cygwin switch > changes the build environment from Cygwin to MinGW. > > > In his last email on this topic, Robert Collins confirmed for me that it > > would be appropriate to specify --build=i686-pc-cygwin > > and --host=i686-pc-mingw32. (I've intentionally left --target > > out since it's not pertinent to this part of the discussion). > > > > And if `gcc -mno-cygwin' where a true cross build system then yes it > apples. However, it's not and the -mno-cygwin changes the build > environment to mingw32. > > > Actually, it was me (not the poster) that has an "mgcc" wrapper > > script. I was the one who suggested it. > > > > I still don't understand why I'd want to symlink the binutils > > binaries. I WANT the Cygwin binutils. They don't generate > > object code; they operate on it. The Cygwin binutils do a > > fine job (as Cygwin binaries) operating on MinGW binaries. > > I've never had a problem. > > > > To emulate the cross build system. Then you could safely use the > switches as you desire. > Earnie and Robert, I'm a bit confused when I consider the commentary that you both have contributed on this topic. Here's what I have assessed. You two guys correct me where I'm wrong. === Robert has implied that using GCC with -mno-cygwin is virtually a cross-compile and should be treated as such. An up-to-date and well written configure script would require that the user have i686-pc-mingw32-gcc (which as a script or a binary invokes gcc -mno-cygwin). He would not necessarily need to symlink other binutils to i686-pc-mingw32- because the configure script would find the build (Cygwin) tools after checking for the host tools. He would invoke configure with the following: $ ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 \ [--target=i686-pc-mingw32] Specification of target is optional since it will get the value of host. If one were invoking a configure script generated by an OLDER version of autoconf, he'd have to set CC in the environment to point to the executable that invokes "gcc -mno-cygwin". Since the cross-compiling aspect would not be working correctly, the name of the executable does not HAVE to be i686-pc-mingw32-gcc. It could, for instance, be mgcc. The invocation might look like this: $ env CC=mgcc ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 \ [--target=i686-pc-mingw32] === Earnie. Your comments seem to contradict each other. In your last email, it seems you are implying that "gcc -mno-cygwin" is NOT a cross-compile. And then you went on to explain how I could safely use the switches if I set symlinks to emulate a cross-compile. Which point of view do you support Earnie? It seems as though for the most part, you do not agree with Robert's point of view, i.e. that using "gcc -mno-cygwin" is NOT a cross-compile, that MinGW IS the build environment. Thus, you have implied that one invokes with the following (assuming configure script is up-to-date and well-written): $ ./configure --build=i686-pc-mingw32 --host=i686-pc-mingw32 \ --target=i686-pc-mingw32 I believe that target would still be optional, since it will get the value of host. Agreed? As we know (because Robert has verified), build WILL get the value of host with the lastest autoconf. In that respect, even build is optional. HOWEVER, since the intended future behavior is for build to be tested no matter what, then its specification WOULD be necessary. Well we still have a problem. Since build and host ARE the same, then we're NOT doing a cross-compile, and configure will NOT look for ${host}-gcc or any other ${host}-tool. It would STILL be necessary to set CC appropriately. The original invocation that I had posted was: $ env CC=mgcc ./configure --host=i686-pc-mingw32 You said this was wrong. To be consisent with future behavior, it seems that I must specify build. So if you're suggesting that I'm not cross-compiling, then it would be: $ env CC=mgcc ./configure --host=i686-pc-mingw32 --build=i686-pc-mingw32 Would you still say that setting CC above is wrong? If so, how will configure find the executable that invokes "gcc -mno-cygwin"? Also, if cross-compiling is wrong, then why would I ever want to define any ${host}- symlinks? Jon -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/