RE: Compiling apps to Mingw32 with cygwin

["Jon Leichter" <jonleichter@mediaone.net>]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Earnie Boyd
> Sent: Friday, January 11, 2002 4:01 AM
> To: Jon Leichter
> Cc: hschwentner@yahoo.com; cygwin@cygwin.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-<tool> 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}-<tool> 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/