From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7862 invoked by alias); 11 Jan 2002 12:01:54 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Received: (qmail 7765 invoked from network); 11 Jan 2002 12:01:45 -0000 Received: from unknown (HELO smtp015.mail.yahoo.com) (216.136.173.59) by sources.redhat.com with SMTP; 11 Jan 2002 12:01:45 -0000 Received: from gate1.lci.net (HELO yahoo.com) (150.159.224.8) by smtp.mail.vip.sc5.yahoo.com with SMTP; 11 Jan 2002 12:01:44 -0000 Message-ID: <3C3ED3F6.9DD9A87C@yahoo.com> Date: Fri, 11 Jan 2002 04:11:00 -0000 From: Earnie Boyd Reply-To: CU List X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon Leichter CC: hschwentner@yahoo.com, cygwin@cygwin.com Subject: Re: Compiling apps to Mingw32 with cygwin References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00757.txt.bz2 Jon Leichter wrote: > > > -----Original Message----- > > From: Earnie Boyd [mailto:earnie_boyd@yahoo.com] > > Sent: Thursday, January 10, 2002 2:31 PM > > To: Jon Leichter > > Cc: cygwin@cygwin.com; hschwentner@yahoo.com > > Subject: Re: Compiling apps to Mingw32 with cygwin > > > > Using `gcc -mno-cygwin' is switching the build environment to MinGW. It > > says use the headers in /usr/include/mingw instead of /usr/include and > > to use the libraries in /usr/lib/mingw instead of the ones in /usr/lib. > > Thus you're switching the build environment to MinGW. > > I already understand the implications of using the -mno-cygwin switch. To be > more precise, -mno-cygwin does NOT tell GCC to use /usr/lib/mingw INSTEAD of > the ones in /usr/lib. GCC, by generic default, will ALWAYS look in /usr/lib > if it doesn't find the libraries it's looking for elsewhere. I recently > posted a topic about this. > > 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 > binaries, but the switch is actually driven by the specs file. 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. > > > The symlink approach (i.e. i386-pc-mingw32-gcc) might be appropriate for > > > > No, the poster has a wrapper script he named mgcc. The symlink was for > > binutils binaries. > > 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. > > > latter versions of autoconf, but it does not work for earlier > > versions. I > > > contribute to the OpenLDAP project, specifically its MinGW > > support. To build > > > MinGW OpenLDAP, I've also got to build regex-0.12, gdbm-1.8.0, and > > > libtool-1.4.2. As far as I can tell, none of the configure > > scripts in these > > > projects conform to the notion of looking for ${host}-gcc or any other > > > ${host}-tool. In these projects, the solution I pointed out works > > > flawlessly: > > > > > > CC=mgcc ./configure --host=i686-pc-mingw32 > > > > > > > Not all configure.in contains AC_CANONICAL_SYSTEM. Try ones that do. > > E.G.: binutils, gcc. > > I understand that configure.in scripts written "properly" or in a standard > manner will make "proper" use of --host, --build, and --target. My point is > that not all projects do use it properly. It still requires that the project > builder be aware. Without awareness, more and more people will post to > mailing lists stating: "Hey, I used these switches as documented in > Autoconf, and it didn't work right." > Which should mean that the maintainer of the package at least get a bug fix report with patch so that the next release has it corrected. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- 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/