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 Message-ID: <3C3E1607.EB5DD087@yahoo.com> Date: Thu, 10 Jan 2002 17:30:31 -0500 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: cygwin AT cygwin DOT com, hschwentner AT yahoo DOT com Subject: Re: Compiling apps to Mingw32 with cygwin References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jon Leichter wrote: > > Earnie Boyd wrote: > > Your wrapper script is a good idea but has the wrong name as has been > > pointed out already. It needs to be named i386-pc-mingw32-gcc and a > > copy as mingw32-gcc so that when specifying the --host=mingw32 or > > --host=i386-pc-mingw32 the configure script will find it appropriately. > > Of course to do this you also need to do the same for the binutils > > binaries. > > > > Yes, specifying --host without the other parts of the triplet indicates > > a cross build to configure. You are even warned of this fact. Specify > > all three to avoid configure from figuring it out on it's own. You've > > just been lucky enough to not configure a package that cares. Try > > configuring binutils if you want to see what happens with just > > specifying host. > > J. Henning Schwentner wrote: > > Dear Earnie, > > > > I do not get it with the --build switch. Am I not building on > > i686-pc-cygwin? Is it i368-pc-mingw because I use the mingw-headers? > > But I use the cygwin-compiler. > > > > Sorry, but I am confused a bit ... > > Earnie, I'm confused too. > 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. > 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. > 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. > The configure script in regex-0.12 does not even accept the --host switch > (or --target or --build). Instead, it treats the last parameter on the > command line as the "host": > > CC=mgcc ./configure i686-pc-mingw32 > Must have been built using and older version of autoconf. This method is deprecated and will most likely support for this will be removed with version 3.0. > The configure script in regex-0.12 does not make any real use of this value, > so it doesn't really have any effect on the build. > Not all configure.in conform to the standard obviously. My statements are based on the standard. > I originally responded to J. Henning Schwentner, who started this thread. At > this point, I don't remember what he said he was building. However, it's > obvious to me that unless you're building a project with a configure script > built by an up-to-date version of autoconf, none of what you have suggested > will work. Note that the approach I suggested will work in either case, WITH > THE POSSIBLE EXCEPTION (as you have stated) that one runs into trouble > if --build and --target are not specified as well. > My statements are based on the standard. For those packages conforming to AC_CAN0NICAL_SYSTEM my statements will make a difference. I'm saying you should just get used to always doing it that way so that you never have a problem. Fine if you don't, you will find the package that needs it. > This spawns another associated topic. What are the right values for the > triplets (in CURRENT autoconf)? If you're building MinGW binaries in a > Cygwin-hosted environment, it seems to me that you should ONLY > specify --target=i686-pc-mingw32 and let the other two switches resolve > themselves to i686-pc-cygwin. When I build MinGW binaries with Cygwin tools, > I am not using a MinGW-hosted environment or MinGW tools. All of binutils, > for example, are still Cygwin tools, and they DON'T honor the -mno-cygwin > switch. I don't want to symlink those tools either. None of this should > matter as long as GCC produces MinGW binaries. Why should it matter if > configure believes that you're doing a cross-compile. In a loose sense, you > are. This, of course, is a religious argument. > It depends on the filters in your config.sub. > Note that I have tried to only use the --target switch in my projects, > opposed to the --host switch. However, in OpenLDAP and the other related > projects, NONE of the configure scripts handle these switches correctly. I > found that using --host was the best solution for these projects. > Host is the environment the resulting binaries will execute on. Build is the environment doing the building. Target is the environment that the resulting binaries for host will produce. Not all packages need the target but if the configure script is AC_CANONICAL_SYSTEM aware then it will look for i686-pc-mingw32-gcc (to use your example of host from above) and associated binaries similarly named if you supply host without build. > Indeed, until the latest version of autoconf makes its way into all projects > as a standard, these switches will need to be examined by the project > builder in order to have context on how to build. > I suggest that if you find buggy configure.in and/or Makefile.in files that you patch it and send the patch to the package maintainer instead of waiting for someone else to do it. HTH, 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/