From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5776 invoked by alias); 12 Jan 2002 18:06:42 -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 5742 invoked from network); 12 Jan 2002 18:06:41 -0000 Received: from unknown (HELO smtp013.mail.yahoo.com) (216.136.173.57) by sources.redhat.com with SMTP; 12 Jan 2002 18:06:41 -0000 Received: from gate1.lci.net (HELO yahoo.com) (150.159.224.8) by smtp.mail.vip.sc5.yahoo.com with SMTP; 12 Jan 2002 18:06:40 -0000 Message-ID: <3C407AFB.DC2871B5@yahoo.com> Date: Sat, 12 Jan 2002 12:51:00 -0000 From: Earnie Boyd X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon Leichter CC: robert.collins@itdomain.com.au, 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/msg00838.txt.bz2 Jon Leichter wrote: > > 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? > 1) `gcc -mno-cygwin' is not a cross compile. 2) it is possible to emulate a cross build system using a scripted `gcc -mno-cygwin' and symlinks. 3) `gcc -mno-cygwin' switches the build environment from Cygwin to MinGW. Therefore > 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 > And > I believe that target would still be optional, since it will get the value > of host. Agreed? > yes target is optional. However, host and build are not because config.guess would guess wrong. > 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. > Shrug, use it a you don't loose. Don't use it and you might loose. Specifying the System Type ========================== Like other GNU `configure' scripts, Autoconf-generated `configure' scripts can make decisions based on a canonical name for the system type, which has the form: `CPU-VENDOR-OS', where OS can be `SYSTEM' or `KERNEL-SYSTEM' `configure' can usually guess the canonical name for the type of system it's running on. To do so it runs a script called `config.guess', which infers the name using the `uname' command or symbols predefined by the C preprocessor. Alternately, the user can specify the system type with command line arguments to `configure'. Doing so is necessary when cross-compiling. In the most complex case of cross-compiling, three system types are involved. The options to specify them are(1): `--build=BUILD-TYPE' the type of system on which the package is being configured and compiled. `--host=HOST-TYPE' the type of system on which the package will run. `--target=TARGET-TYPE' the type of system for which any compiler tools in the package will produce code (rarely needed). By default, it is the same as host. They all default to the result of running `config.guess', unless you specify either `--build' or `--host'. In this case, the default becomes the system type you specified. If you specify both, and they're different, `configure' will enter cross compilation mode, so it won't run any tests that require execution. Hint: if you mean to override the result of `config.guess', prefer `--build' over `--host'. In the future, `--host' will not override the name of the build system type. Also, if you specify `--host', but not `--build', when `configure' performs the first compiler test it will try to run an executable produced by the compiler. If the execution fails, it will enter cross-compilation mode. Note, however, that it won't guess the build-system type, since this may require running test programs. Moreover, by the time the compiler test is performed, it may be too late to modify the build-system type: other tests may have already been performed. Therefore, whenever you specify `--host', be sure to specify `--build' too. ./configure --build=i686-pc-linux-gnu --host=m68k-coff will enter cross-compilation mode, but `configure' will fail if it can't run the code generated by the specified compiler if you configure as follows: ./configure CC=m68k-coff-gcc `configure' recognizes short aliases for many system types; for example, `decstation' can be used instead of `mips-dec-ultrix4.2'. `configure' runs a script called `config.sub' to canonicalize system type aliases. ---------- Footnotes ---------- (1) For backward compatibility, `configure' will accept a system type as an option by itself. Such an option will override the defaults for build, host and target system types. The following configure statement will configure a cross toolchain that will run on NetBSD/alpha but generate code for GNU Hurd/sparc, which is also the build platform. ./configure --host=alpha-netbsd sparc-gnu > 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 > If it works for you, use it. It seems to be supported even if it's just backward compatibility. > 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 > This is what I would do. > Would you still say that setting CC above is wrong? If so, how will > configure find the executable that invokes "gcc -mno-cygwin"? > No, you must set the CC yourself or modify the m4 code that searches for a default compiler. However, with autoconf-2.50 and greater it's suggested that you do ./configure CC=mgcc --host=i686-pc-mingw32 --build=i686-pc-mingw32 as configure will store the CC variable in the config.status file. > Also, if cross-compiling is wrong, then why would I ever want to define any > ${host}- symlinks? > Cross compiling itself isn't wrong so I'm going to assume you mean `gcc -mno-cygwin' isn't cross compiling. So that you can emulate cross compiling, i.e. --host=i686-pc-mingw32 --build=i686-pc-cygwin will cause a proper configure to search for i686-pc-mingw32-gcc. For clarification, I was thinking that --host without --build would cause the build environment to be guessed. I must have been confused with future plans for autoconf. There was discussion about this on the autoconf list months ago if you care to research the autoconf archives. Hmm... Here's what the info file says: - Macro: AC_CANONICAL_HOST Compute the canonical host-system type variable, `host', and its three individual parts `host_cpu', `host_vendor', and `host_os'. If `--host' was specified, then `host' is the canonicalization of `host_alias' by `config.sub', otherwise it defaults to `build'. For temporary backward-compatibility, when `--host' is specified but `--build' isn't, the build system will be assumed to be the same as `--host', and `build_alias' will be set to that value. Eventually, this historically incorrect behavior will go away. 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/