RE: Compiling apps to Mingw32 with cygwin

RE: Compiling apps to Mingw32 with cygwin

[Bernard Dautrevaux]

> -----Original Message-----
> From: J. Henning Schwentner [mailto:hschwentner@yahoo.com]
> Sent: Sunday, January 06, 2002 2:57 PM
> To: cygwin@cygwin.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
> 
> 
> Thanks for your quick help, this works nice!
> 
> But, it is a bit difficult. I think ideally configure should detect 
> --host=mingw32 --build=cygwin and in this case should add 
> --mno-cygwin to 
> CFLAGS and CPPFLAGS (and do something to fix libtool).
> 
> I am not sure if this is a bit off topic, maybe this sould be 
> posted to the 
> autoconf list.

In fact if you do 
	./configure --host=i386-pc-mingw32
The autoconf shoudl automagically select a cross compiler for you, if ever
it finds one named '$host-gcc' in your path. So if you put Jon's script in
/usr/bin but name it 'i386-pc-mingw32-gcc', autoconf should get it
automatically.

WARNING: I've not time to test it right, so I don't remember for sure if
autoconf will try '$host-gcc' or '$host_alias-gcc' where $host_alias is what
you pass as a --host argument and $host is the canonicalised host name
(result of config.sub $host_alias).

HTH

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
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/

Re: Compiling apps to Mingw32 with cygwin

[Earnie Boyd]

> Subject: Re: Compiling apps to Mingw32 with cygwin
> Date: Fri, 11 Jan 2002 13:25:17 +1100
> From: "Robert Collins" <robert.collins@itdomain.com.au>
> To: "Jon Leichter" <jon@symas.com>
> CC: <cygwin@cygwin.com>
> 
> ----- Original Message -----
> From: "Jon Leichter" <jon@symas.com>
> > > See above why it doesn't. mingw != cygwin :}.
> >
> > If 'build' WERE to be tested automatically, independent to 'host', it
> would
> > come up with 'i686-pc-cygwin'. Thus, we'd effectively end up with the
> same
> > line you specified above. So that does work, right? Or are you trying
> to
> > confuse me again??? :)
> 
> What doesn't kill us makes us stronger. IF build were tested correctly
> yes. But it's not currently tested - it defaults to host IFF host is
> defined.
> 

This rule is changed for 2.50 and greater.  Build no longer takes on the
value of host and you're warned about this when specifying --host
without specifying --build.  IIRC, if you specify build without host
then host takes on the value of build but I may be wrong on this point.

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

===
----- Original Message -----
From: "Earnie Boyd" <earnie_boyd@yahoo.com>
>
> This rule is changed for 2.50 and greater.  Build no longer takes on
the
> value of host and you're warned about this when specifying --host
> without specifying --build.  IIRC, if you specify build without host
> then host takes on the value of build but I may be wrong on this
point.

The autoconf 2.5 manual specifies that build takes on the value of host
AND that a warning is generated. I've also checked the generated macros,
and that is the behaviour.

I too thought that the build was checked if --host was specified but
build omited in 2.5 which is why I investigated.

Rob


--
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/

Re: Compiling apps to Mingw32 with cygwin

[Earnie Boyd]

> Subject: RE: Compiling apps to Mingw32 with cygwin
> Date: Thu, 10 Jan 2002 17:20:42 -0800
> From: "Jon Leichter" <jon@symas.com>
> To: "Robert Collins" <robert.collins@itdomain.com.au>
> CC: <cygwin@cygwin.com>
> 
> Ok. I need to return to asking some questions with my new understanding
> of --build, --host, and --target (which I'm incredibly grateful for and
> happy about).
> 
> I have returned to working with OpenLDAP. The configure script is generated
> with autconf-2.13.1. It uses AC_CANONICAL_SYSTEM, which you say is
> deprecated. I assume, however, that it still works to some extent.
> 
> I tried to configure with the following:
> 
>         $ ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32
> 
> I've left --target off, since I know it will get the value of --host, which
> is what I want. It does.
> 
> First, some questions:
> 
> - What is correct: i386-pc-mingw32 or i686-pc-mingw32? If one is correct,
> why? If both are correct, how does one decide which one to use?
> 
> - I notice that if I merely use --host=mingw32, config.guess will equate
> "mingw32" as "i386-unknown-mingw32". Why?
> 

It comes from config.sub.  The config.guess is used to guess the system
but you've specified it so it's not executed.

> - Is there a plan to get "32" from "mingw32", i.e. "mingw"? Of course, that
> won't be useful with old projects that still need the "32" to be present...
> :(
> 

No.  mingw32 will always be the target for Win32.  Look at the archives
for the mingw-users list.

> ===
> 
> Now my results:
> 
> - I never see configure look for i686-pc-mingw32-gcc. It merely picks up
> 'gcc'. Any ideas why?
> 

Your configure script was created with an autoconf older than 2.50. 
Prior versions check to see if the you cross building by trying to
execute a test program.  If it runs then it's not a cross build. 
Version 2.50 changed that to compare the values of host and build.

You could modify the config.cache and change the value for the cross
variable from no to yes and reexecute the configure script to get 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/

RE: Compiling apps to Mingw32 with cygwin

[Bernard Dautrevaux]

> -----Original Message-----
> From: Earnie Boyd [mailto:earnie_boyd@yahoo.com]
> Sent: Wednesday, January 09, 2002 8:42 PM
> To: CU List
> Subject: Re: Compiling apps to Mingw32 with cygwin
> 
> 
> > Subject: Re: Compiling apps to Mingw32 with cygwin
> > Date: Wed, 9 Jan 2002 18:11:16 +0100
> > From: "J. Henning Schwentner" <hschwentner@yahoo.com>
> > To: cygwin@cygwin.com
> > 
> > Am Montag, 7. Januar 2002 17:49 schrieben Sie:
> > > Jon Leichter wrote:
> > > > - Using CC="gcc -mno-cygwin" is good for compiling, but 
> it's bad for GNU
> > > > Libtool, as I have mentioned. I use a wrapper script: 
> CC=mgcc. What do
> > > > you think of this Earnie?
> > >
> > > 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.
> > 
> > Do the binutils also support the -mno-cygwin switch? 
> 
> I'll leave that as an exercise for you to figure out.
> 
> > Or can the
> > 386-pc-mingw32-<binutilname> files be simple links to the 
> cygwin versions?
> > 
> 
> Yes, simply symlink will do.

So the simlink is not needed at all: if autotools don't find, say
"i386-pc-mingw32-ar", they'll look for plain "ar" and use it. So no need to
mind with these symlinks. Just creating the script/exec i386-pc-mingw32-gcc
will be enough (and a i386-pc-mingw32-g++ link to it when we get a mingw32
libstdc++ of course :)).

Regards

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

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.

The symlink approach (i.e. i386-pc-mingw32-gcc) might be appropriate for
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

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

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.

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.

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.

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.

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.

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "Jon Leichter" <jon@symas.com>

I hope I don't repeat anything from this thread, I've only been scanning
it lightly.

..
> 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.

Autoconf 2.13 supports these options - so the configure script doesn't
need to be *that* up to date.

However, the script needs
AC_CANONICAL_BUILD
AC_CANONICAL_HOST
(and if the package generates platform specific output (ie it's an
assembler/compiler etc)
AC_CANONICAL_TARGET
in the configure.in. You may need to add the relevant macros and run
autoconf again.

As for --build, it is automatically detected as long as
AC_CANONICAL_BUILD is in the script. You may get a warning
==
configure: WARNING: If you wanted to set the --build type, don't
use --host.
    If a cross compiler is detected then cross compile mode will be
used.
==
This warning is safe IFF you have a cross compiler.

> 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

No. Specify --host. The meaning is clearly documented in the autoconf
documentation.
For clarity:
build - what OS the compilation is running on..
host  - what OS the binaries created should run on.
target - what OS the binaries created should target their output to.

> 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.

--target being the wrong switch, I'm not surprised it didn't do what you
wanted :}.

Rob


--
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/

Re: Compiling apps to Mingw32 with cygwin

[Charles Wilson]

Robert Collins wrote:

> No. Specify --host. The meaning is clearly documented in the autoconf
> documentation.
> For clarity:
> build - what OS the compilation is running on..
> host  - what OS the binaries created should run on.
> target - what OS the binaries created should target their output to.


Thank you thank you thank you.  I have *never* really understood what 
all those were *really* for -- only what I *thought* they were for. 
Guess what -- I was wrong.  I thought (wrongly)

host: what OS the compilation is running on
target: what OS the binaries created should run on
build: And I never understood what this was for.

THANKS for the succinct explanation.  I'm going to tattoo this on my 
arm.  (Well, not really, but you get the idea)

--Chuck



--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Robert Collins
> Sent: Thursday, January 10, 2002 1:44 PM
> To: cygwin@cygwin.com
> Cc: hschwentner@yahoo.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
> Autoconf 2.13 supports these options - so the configure script doesn't
> need to be *that* up to date.
>
> However, the script needs
> AC_CANONICAL_BUILD
> AC_CANONICAL_HOST
> (and if the package generates platform specific output (ie it's an
> assembler/compiler etc)
> AC_CANONICAL_TARGET
> in the configure.in. You may need to add the relevant macros and run
> autoconf again.
>
> As for --build, it is automatically detected as long as
> AC_CANONICAL_BUILD is in the script. You may get a warning
> ==
> configure: WARNING: If you wanted to set the --build type, don't
> use --host.
>     If a cross compiler is detected then cross compile mode will be
> used.
> ==
> This warning is safe IFF you have a cross compiler.

Ok. Definitely some misunderstandings on my part. So, I will restate:

For any particular project, the --build, --host, --target switches are not
guaranteed to be work "properly". This will depend on how well configure.in
has been written. In that respect, the project builder STILL needs to
manually check the 'configure' script (or just try to use it and see what
happens).

>
> > 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.
>
> No. Specify --host. The meaning is clearly documented in the autoconf
> documentation.
> For clarity:
> build - what OS the compilation is running on..
> host  - what OS the binaries created should run on.
> target - what OS the binaries created should target their output to.

Actually, I'm a little unclear. Are you saying that 'target' is for binaries
that you build, which in themselves, generate other binaries? Would an
example of this be GCC? Would I still need to "properly" specify --target if
I wasn't building binaries that generated binaries? Would you then say that
the following is the appropriate set of switches for Cygwin-GCC to produce
MinGW binaries:

	--build=i686-pc-cygwin --host=i686-pc-mingw32 --target=i686-pc-mingw32

Can I leave out the --build switch? Will it get automatically resolved? Or
does that ALSO depend on how well configure.in was written? In the configure
scripts I've used, I have consistently seen the 'build' variables get
assigned the same values as the 'host' variables.

> > 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.
>
> --target being the wrong switch, I'm not surprised it didn't do what you
> wanted :}.
>

Ok. Once I've had my switch questions answered, I will go back and see how
well those switches play in my projects.

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "Jon Leichter" <jon@symas.com>

> > No. Specify --host. The meaning is clearly documented in the
autoconf
> > documentation.
> > For clarity:
> > build - what OS the compilation is running on..
> > host  - what OS the binaries created should run on.
> > target - what OS the binaries created should target their output to.
>
> Actually, I'm a little unclear. Are you saying that 'target' is for
binaries
> that you build, which in themselves, generate other binaries? Would an
> example of this be GCC?

Yes. The way they are used is kinda cool. Imagine that you've got a new
platform (say wince). It's got no gcc at the moment, and the c compiler
you've got for it is brain-dead (can't host a two-stage gcc build). You
do have a C library that should build for it.
What you do is:
build gcc+binutils with --build=here --host=here --target=wince
and then build the C library for that platform. Place those libraries in
an appropriate search location (ie /usr/local/lib/wince :})
then you
build gcc+binutils with --build=here --host=wince --target=wince
and then you copy the resulting binaries to the target platform, and
finally can build
gcc as a native 3 step boot strap, to ensure everything is ok. i.e. (for
completeness)
build gcc+binutils with --build=wince --host=wince --target=wince

> Would I still need to "properly" specify --target if
> I wasn't building binaries that generated binaries? Would you then say
that
> the following is the appropriate set of switches for Cygwin-GCC to
produce
> MinGW binaries:

Target can be safely skipped if you know for sure that the package does
not create platform specific output. I'm not saying 'binaries' here
because there are other forms of platform specific output that may
exist.

> --build=i686-pc-cygwin --host=i686-pc-mingw32 --target=i686-pc-mingw32

Yes, that should work. GCC will look for a i686-pc-mingw32 cross
compiler.

> Can I leave out the --build switch? Will it get automatically
resolved? Or

Thats what I said :}. I was wrong (I've just rechecked).

In theory I'm right, but for backward compatability, if you specify
host, but not build, then build is set to host. This is (obviously)
wrong and will eventually get removed. For now specify both build and
host explicitly. (which is a bummer for cross- scripts (because the user
must then know what build is, or the script must duplicate what
config.guess and config.sub do.).

> does that ALSO depend on how well configure.in was written? In the
configure
> scripts I've used, I have consistently seen the 'build' variables get
> assigned the same values as the 'host' variables.

You've seen broken scripts then. There may well be brain damaged scripts
around.

See http://www.gnu.org/manual/autoconf/html_mono/autoconf.html#SEC117

Rob


--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

Robert,

This all now makes a lot more sense to me. Those switch definitions have
confused me for a long time.

Thank you.

Jon

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Robert Collins
> Sent: Thursday, January 10, 2002 2:28 PM
> To: Jon Leichter
> Cc: hschwentner@yahoo.com; cygwin@cygwin.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
>
> ----- Original Message -----
> From: "Jon Leichter" <jon@symas.com>
>
> > > No. Specify --host. The meaning is clearly documented in the
> autoconf
> > > documentation.
> > > For clarity:
> > > build - what OS the compilation is running on..
> > > host  - what OS the binaries created should run on.
> > > target - what OS the binaries created should target their output to.
> >
> > Actually, I'm a little unclear. Are you saying that 'target' is for
> binaries
> > that you build, which in themselves, generate other binaries? Would an
> > example of this be GCC?
>
> Yes. The way they are used is kinda cool. Imagine that you've got a new
> platform (say wince). It's got no gcc at the moment, and the c compiler
> you've got for it is brain-dead (can't host a two-stage gcc build). You
> do have a C library that should build for it.
> What you do is:
> build gcc+binutils with --build=here --host=here --target=wince
> and then build the C library for that platform. Place those libraries in
> an appropriate search location (ie /usr/local/lib/wince :})
> then you
> build gcc+binutils with --build=here --host=wince --target=wince
> and then you copy the resulting binaries to the target platform, and
> finally can build
> gcc as a native 3 step boot strap, to ensure everything is ok. i.e. (for
> completeness)
> build gcc+binutils with --build=wince --host=wince --target=wince
>
> > Would I still need to "properly" specify --target if
> > I wasn't building binaries that generated binaries? Would you then say
> that
> > the following is the appropriate set of switches for Cygwin-GCC to
> produce
> > MinGW binaries:
>
> Target can be safely skipped if you know for sure that the package does
> not create platform specific output. I'm not saying 'binaries' here
> because there are other forms of platform specific output that may
> exist.
>
> > --build=i686-pc-cygwin --host=i686-pc-mingw32 --target=i686-pc-mingw32
>
> Yes, that should work. GCC will look for a i686-pc-mingw32 cross
> compiler.
>
> > Can I leave out the --build switch? Will it get automatically
> resolved? Or
>
> Thats what I said :}. I was wrong (I've just rechecked).
>
> In theory I'm right, but for backward compatability, if you specify
> host, but not build, then build is set to host. This is (obviously)
> wrong and will eventually get removed. For now specify both build and
> host explicitly. (which is a bummer for cross- scripts (because the user
> must then know what build is, or the script must duplicate what
> config.guess and config.sub do.).
>
> > does that ALSO depend on how well configure.in was written? In the
> configure
> > scripts I've used, I have consistently seen the 'build' variables get
> > assigned the same values as the 'host' variables.
>
> You've seen broken scripts then. There may well be brain damaged scripts
> around.
>
> See http://www.gnu.org/manual/autoconf/html_mono/autoconf.html#SEC117
>
> Rob
>
>
> --
> 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/
>
>
>


--
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/

Re: Compiling apps to Mingw32 with cygwin

[Earnie Boyd]

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

===
----- Original Message -----
From: "Earnie Boyd" <earnie_boyd@yahoo.com>
> 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.

BTW: According to
http://www.gnu.org/manual/autoconf/html_mono/autoconf.html#SEC144
AC_CANONICAL_SYSTEM is obsolete.

Rob


--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

> -----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.
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).

> > 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.

> > 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."

> > 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.

Of course it's an older version, and I figured it was deprecated. It doesn't
change the fact that anyone wanting to build this package has to deal with
it the way it is.

> > 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.

That's fine. My statements are about projects that DON'T conform to 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.

Now that I understand the switches better, I plan to use them properly as
often as possible.

> > 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.
>

It's true that I don't usually patch the script myself and send it back. In
some cases, there isn't any organization to send the patches back to, e.g.
GDBM. This is not an unsubstaniated statement. I sent patches to GDBM years
ago, and nothing ever came of it.

I'm not really waiting for someone else to fix these problems. I usually
find a way to work around the problems. Furthermore, since I am not making
the patches, then I probably don't have the right to complain. That said,
I'm not really complaining. The topic has come up, and I am responding with
my thoughts.

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

===
----- Original Message -----
From: "Jon Leichter" <jon@symas.com>
> 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.

Because when autoconf is cross compiling (that is, when _host_!=_build_)
it looks for compilers and binutils utilities named with a prefix of the
_target_ they where built for.

IOW when you configure foo
with --build=i686-pc-cygwin --host=i686-pc-mingw32
autoconf looks for gcc and binutils created via:
configure --build=wherever --host=i686-pc-cygwin --target=i686-pc-mingw3
2
(note that the gcc/binutil HOST is == to the foo BUILD). Those
gc+binutils files get named with a prefix == the target they arebuilt
for (that is i686-pc-mingw32).

Now the cygwin standard gcc and binutils (which are prefixed with
i686-pc-cygwin can happily generate mingw32 code, so the symlink
i686-pc-mingw32 lets autoconf find what it expects.

Rob


--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

Ok. I need to return to asking some questions with my new understanding
of --build, --host, and --target (which I'm incredibly grateful for and
happy about).

I have returned to working with OpenLDAP. The configure script is generated
with autconf-2.13.1. It uses AC_CANONICAL_SYSTEM, which you say is
deprecated. I assume, however, that it still works to some extent.

I tried to configure with the following:

	$ ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32

I've left --target off, since I know it will get the value of --host, which
is what I want. It does.

First, some questions:

- What is correct: i386-pc-mingw32 or i686-pc-mingw32? If one is correct,
why? If both are correct, how does one decide which one to use?

- I notice that if I merely use --host=mingw32, config.guess will equate
"mingw32" as "i386-unknown-mingw32". Why?

- Is there a plan to get "32" from "mingw32", i.e. "mingw"? Of course, that
won't be useful with old projects that still need the "32" to be present...
:(

===

Now my results:

- I never see configure look for i686-pc-mingw32-gcc. It merely picks up
'gcc'. Any ideas why?

- I DO see configure look for ${host} binutils, i.e. i686-pc-mingw32-<tool>,
but since I don't have symlinks, it finds unprefixed versions of the tools.
This, of course, is what I want to happen.

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "Jon Leichter" <jon@symas.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <cygwin@cygwin.com>
Sent: Friday, January 11, 2002 12:20 PM
Subject: RE: Compiling apps to Mingw32 with cygwin


> Ok. I need to return to asking some questions with my new
understanding
> of --build, --host, and --target (which I'm incredibly grateful for
and
> happy about).
>
> I have returned to working with OpenLDAP. The configure script is
generated
> with autconf-2.13.1. It uses AC_CANONICAL_SYSTEM, which you say is
> deprecated. I assume, however, that it still works to some extent.
>
> I tried to configure with the following:
>
> $ ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32
>
> I've left --target off, since I know it will get the value of --host,
which
> is what I want. It does.
>
> First, some questions:
>
> - What is correct: i386-pc-mingw32 or i686-pc-mingw32? If one is
correct,
> why? If both are correct, how does one decide which one to use?
>
> - I notice that if I merely use --host=mingw32, config.guess will
equate
> "mingw32" as "i386-unknown-mingw32". Why?
>
> - Is there a plan to get "32" from "mingw32", i.e. "mingw"? Of course,
that
> won't be useful with old projects that still need the "32" to be
present...
> :(
>
> ===
>
> Now my results:
>
> - I never see configure look for i686-pc-mingw32-gcc. It merely picks
up
> 'gcc'. Any ideas why?

Do you have an accessible i686-pc-mingw32-gcc ?

have a look at the configure script - it may provide some clues :}.

Rob


--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

> -----Original Message-----
> From: Robert Collins [mailto:robert.collins@itdomain.com.au]
> Sent: Thursday, January 10, 2002 5:27 PM
> To: Jon Leichter
> Cc: cygwin@cygwin.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
>
> ----- Original Message -----
> From: "Jon Leichter" <jon@symas.com>
> To: "Robert Collins" <robert.collins@itdomain.com.au>
> Cc: <cygwin@cygwin.com>
> Sent: Friday, January 11, 2002 12:20 PM
> Subject: RE: Compiling apps to Mingw32 with cygwin
>
>
> > Ok. I need to return to asking some questions with my new
> understanding
> > of --build, --host, and --target (which I'm incredibly grateful for
> and
> > happy about).
> >
> > I have returned to working with OpenLDAP. The configure script is
> generated
> > with autconf-2.13.1. It uses AC_CANONICAL_SYSTEM, which you say is
> > deprecated. I assume, however, that it still works to some extent.
> >
> > I tried to configure with the following:
> >
> > $ ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32
> >
> > I've left --target off, since I know it will get the value of --host,
> which
> > is what I want. It does.
> >
> > First, some questions:
> >
> > - What is correct: i386-pc-mingw32 or i686-pc-mingw32? If one is
> correct,
> > why? If both are correct, how does one decide which one to use?
> >
> > - I notice that if I merely use --host=mingw32, config.guess will
> equate
> > "mingw32" as "i386-unknown-mingw32". Why?
> >
> > - Is there a plan to get "32" from "mingw32", i.e. "mingw"? Of course,
> that
> > won't be useful with old projects that still need the "32" to be
> present...
> > :(
> >
> > ===
> >
> > Now my results:
> >
> > - I never see configure look for i686-pc-mingw32-gcc. It merely picks
> up
> > 'gcc'. Any ideas why?
>
> Do you have an accessible i686-pc-mingw32-gcc ?
>
> have a look at the configure script - it may provide some clues :}.
>
> Rob
>

Sorry... I left that out. Yes, I do have an accessible i686-pc-mingw32-gcc,
and I am looking at the configure script. It just searches for gcc. It
doesn't bother to look for the prefixed tool.

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "Jon Leichter" <jon@symas.com>
> Sorry... I left that out. Yes, I do have an accessible
i686-pc-mingw32-gcc,
> and I am looking at the configure script. It just searches for gcc. It
> doesn't bother to look for the prefixed tool.

Are you sure? Here's the output of a configure script here.

Administrator@LIFELESSWKS /usr/src/squid/t
$ ../auth_rewrite/configure --host=i686-pc-linux --build=i686-pc-cygwin
checking for a BSD compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking whether to enable maintainer-specific portions of Makefiles...
no
*****checking for i686-pc-linux-gcc... no******
checking for gcc... gcc
checking for C compiler default output...

If you don't see that line, then one or more tests are missing from your
configure.in

these two should enable that functionality.
AC_CANONICAL_HOST
AC_PROG_CC

Rob


--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

> -----Original Message-----
> From: Robert Collins [mailto:robert.collins@itdomain.com.au]
> Sent: Thursday, January 10, 2002 5:45 PM
> To: Jon Leichter
> Cc: cygwin@cygwin.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
> ----- Original Message -----
> From: "Jon Leichter" <jon@symas.com>
> > Sorry... I left that out. Yes, I do have an accessible
> i686-pc-mingw32-gcc,
> > and I am looking at the configure script. It just searches for gcc. It
> > doesn't bother to look for the prefixed tool.
>
> Are you sure? Here's the output of a configure script here.
>
> Administrator@LIFELESSWKS /usr/src/squid/t
> $ ../auth_rewrite/configure --host=i686-pc-linux --build=i686-pc-cygwin
> checking for a BSD compatible install... /bin/install -c
> checking whether build environment is sane... yes
> checking for mawk... no
> checking for gawk... gawk
> checking whether make sets ${MAKE}... yes
> checking whether to enable maintainer-specific portions of Makefiles...
> no
> *****checking for i686-pc-linux-gcc... no******
> checking for gcc... gcc
> checking for C compiler default output...
>
> If you don't see that line, then one or more tests are missing from your
> configure.in
>
> these two should enable that functionality.
> AC_CANONICAL_HOST
> AC_PROG_CC
>
> Rob
>

Yes, I'm very sure. A quick investigation has yielded the following:

- In autoconf 2.13 (I don't have 2.13.1), AC_PROG_CC is implemented with
AC_CHECK_PROG.

- In autoconf 2.52, AC_PROG_CC is implemented with AC_CHECK_TOOL.

AC_CHECK_TOOL checks for tools with a ${host} prefix. AC_CHECK_PROG does
not.

In my opinion, this serves as another example that one cannot count on a
configure script being up-to-date.

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "Jon Leichter" <jon@symas.com>

> AC_CHECK_TOOL checks for tools with a ${host} prefix. AC_CHECK_PROG
does
> not.
>
> In my opinion, this serves as another example that one cannot count on
a
> configure script being up-to-date.

Ouchies. I agree - yet another reason for cygwin ports to be updated by
the maintainer :}.

Rov


--
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/

Re: Compiling apps to Mingw32 with cygwin

[Christopher Faylor]

On Fri, Jan 11, 2002 at 12:52:01PM +1100, Robert Collins wrote:
>----- Original Message -----
>From: "Jon Leichter" <jon@symas.com>
>
>>AC_CHECK_TOOL checks for tools with a ${host} prefix.  AC_CHECK_PROG
>>does not.
>>
>>In my opinion, this serves as another example that one cannot count on
>>a configure script being up-to-date.
>
>Ouchies.  I agree - yet another reason for cygwin ports to be updated
>by the maintainer :}.

If I am reading this correctly, this is not really a cygwin issue.  It's
a cross-build issue, right?

I build all of the stuff that I support on linux.  For most packages, I
have to do a lot of extra stuff (like set CC, LD, AR, RANLIB on the
command line) to get things built.

cgf

--
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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
> >Ouchies.  I agree - yet another reason for cygwin ports to be updated
> >by the maintainer :}.
       package/port
     ^^^^^^^^^^^^^^^

> If I am reading this correctly, this is not really a cygwin issue.
It's
> a cross-build issue, right?

Not a cygwin issue at all. Only related due to the mingw/cygwin cross
compile question.

Rob


--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

Thus... returning to the ORIGINAL topic of this thread... I had recommended
the following to the OP:

	$ env CC=mgcc ./configure --host=i686-pc-mingw32

My new understanding of switches gives me new perspective. 'build' and
'target' will pickup the value of 'host'. In this context, you're telling
configure that the host == build == MinGW. I've said before that MinGW in
Cygwin is a loose cross-compile. So, it seems to me that this configuration
is ok, especially since 'host' binaries CAN successfully run in the 'build'
environment.

It seems to me that my original solution is suitable whether or not one's
configure script was written "properly" and was built with the latest
autoconf.

We agreed that as of today that 'build', if not specified, gets the value of
'host'. Even if this were to change, i.e. 'build' gets checked for
automatically, my solution STILL works. In this case, it would be a cross
compile, but it should still work.

This leads one to draw the following conclusions:

- If one uses the --host, --build, and --target switches properly, he is not
guaranteed that the configure script will work correctly. It will only work
correctly IFF an up-to-date autoconf generated the script AND the switches
were utilized correctly in configure.in.

- If one uses my method posted above, it will work most (if not all) of the
time. So, it may not be "proper", but it WILL work.

This whole thread went off on a tangent suggesting that my solution was
wrong. So tell me. If my solution works more often than the "proper" one,
how is it wrong?

Jon

> -----Original Message-----
> From: Robert Collins [mailto:robert.collins@itdomain.com.au]
> Sent: Thursday, January 10, 2002 5:52 PM
> To: Jon Leichter
> Cc: cygwin@cygwin.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
> ----- Original Message -----
> From: "Jon Leichter" <jon@symas.com>
>
> > AC_CHECK_TOOL checks for tools with a ${host} prefix. AC_CHECK_PROG
> does
> > not.
> >
> > In my opinion, this serves as another example that one cannot count on
> a
> > configure script being up-to-date.
>
> Ouchies. I agree - yet another reason for cygwin ports to be updated by
> the maintainer :}.
>
> Rov
>
>
>


--
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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "Jon Leichter" <jon@symas.com>


> Thus... returning to the ORIGINAL topic of this thread... I had
recommended
> the following to the OP:
>
> $ env CC=mgcc ./configure --host=i686-pc-mingw32
>
> My new understanding of switches gives me new perspective. 'build' and
> 'target' will pickup the value of 'host'. In this context, you're
telling
> configure that the host == build == MinGW. I've said before that MinGW
in
> Cygwin is a loose cross-compile. So, it seems to me that this
configuration
> is ok, especially since 'host' binaries CAN successfully run in the
'build'
> environment.

Nope. because an autoconf script for mingw32 'build' may expect cp to be
'copy', sh to be cmd.exe and further stuff that will break or misbehave
on cygwin.

 $ env CC=mgcc ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin
is acceptable.

> We agreed that as of today that 'build', if not specified, gets the
value of
> 'host'. Even if this were to change, i.e. 'build' gets checked for
> automatically, my solution STILL works. In this case, it would be a
cross
> compile, but it should still work.

See above why it doesn't. mingw != cygwin :}.

> This leads one to draw the following conclusions:
>
...
> This whole thread went off on a tangent suggesting that my solution
was
> wrong. So tell me. If my solution works more often than the "proper"
one,
> how is it wrong?

Well.. I came in the thread late, so I get to say, 'huh, what, waddya
mean?'.

Rob


--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

> -----Original Message-----
> From: Robert Collins [mailto:robert.collins@itdomain.com.au]
> Sent: Thursday, January 10, 2002 6:16 PM
> To: Jon Leichter
> Cc: cygwin@cygwin.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
>
> ----- Original Message -----
> From: "Jon Leichter" <jon@symas.com>
>
>
> > Thus... returning to the ORIGINAL topic of this thread... I had
> recommended
> > the following to the OP:
> >
> > $ env CC=mgcc ./configure --host=i686-pc-mingw32
> >
> > My new understanding of switches gives me new perspective. 'build' and
> > 'target' will pickup the value of 'host'. In this context, you're
> telling
> > configure that the host == build == MinGW. I've said before that MinGW
> in
> > Cygwin is a loose cross-compile. So, it seems to me that this
> configuration
> > is ok, especially since 'host' binaries CAN successfully run in the
> 'build'
> > environment.
>
> Nope. because an autoconf script for mingw32 'build' may expect cp to be
> 'copy', sh to be cmd.exe and further stuff that will break or misbehave
> on cygwin.

Point taken.

>  $ env CC=mgcc ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin
> is acceptable.

Ok. A mixture of my solution and the explicit addition of the --build
switch. I think I can live with that.

> > We agreed that as of today that 'build', if not specified, gets the
> value of
> > 'host'. Even if this were to change, i.e. 'build' gets checked for
> > automatically, my solution STILL works. In this case, it would be a
> cross
> > compile, but it should still work.
>
> See above why it doesn't. mingw != cygwin :}.

If 'build' WERE to be tested automatically, independent to 'host', it would
come up with 'i686-pc-cygwin'. Thus, we'd effectively end up with the same
line you specified above. So that does work, right? Or are you trying to
confuse me again??? :)

> > This leads one to draw the following conclusions:
> >
> ...
> > This whole thread went off on a tangent suggesting that my solution
> was
> > wrong. So tell me. If my solution works more often than the "proper"
> one,
> > how is it wrong?
>
> Well.. I came in the thread late, so I get to say, 'huh, what, waddya
> mean?'.

Yea, yea, yea... everybody's got an excuse...

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "Jon Leichter" <jon@symas.com>
> > See above why it doesn't. mingw != cygwin :}.
>
> If 'build' WERE to be tested automatically, independent to 'host', it
would
> come up with 'i686-pc-cygwin'. Thus, we'd effectively end up with the
same
> line you specified above. So that does work, right? Or are you trying
to
> confuse me again??? :)

What doesn't kill us makes us stronger. IF build were tested correctly
yes. But it's not currently tested - it defaults to host IFF host is
defined.

Rob


--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

> -----Original Message-----
> From: Robert Collins [mailto:robert.collins@itdomain.com.au]
> Sent: Thursday, January 10, 2002 6:25 PM
> To: Jon Leichter
> Cc: cygwin@cygwin.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
> 
> ----- Original Message -----
> From: "Jon Leichter" <jon@symas.com>
> > > See above why it doesn't. mingw != cygwin :}.
> >
> > If 'build' WERE to be tested automatically, independent to 'host', it
> would
> > come up with 'i686-pc-cygwin'. Thus, we'd effectively end up with the
> same
> > line you specified above. So that does work, right? Or are you trying
> to
> > confuse me again??? :)
> 
> What doesn't kill us makes us stronger. IF build were tested correctly
> yes. But it's not currently tested - it defaults to host IFF host is
> defined.
> 
> Rob
> 

Well, I guess we can put that to rest... whew!   :)

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/

Re: Compiling apps to Mingw32 with cygwin

[Charles Wilson]

Jon Leichter wrote:


> It's true that I don't usually patch the script myself and send it back. In
> some cases, there isn't any organization to send the patches back to, e.g.
> GDBM. This is not an unsubstaniated statement. I sent patches to GDBM years
> ago, and nothing ever came of it.


What patches?  Do they affect functionality, or just the build process? 
  If  <phil@cs.wwu.edu> and  <downsj@downsj.com>  aren't interested, we 
can at least add them to cygwin's gdbm if they provide important bugfixes...

--Chuck
cygwin gdbm maintainer



--
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/

Re: Compiling apps to Mingw32 with cygwin

[Earnie Boyd]

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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

> -----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/

Re: Compiling apps to Mingw32 with cygwin

[Earnie Boyd]

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.

<quote autoconf.info>
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

</guote>

> 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}-<tool> 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:

<quote autoconf.info>
 - 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.
</quote>

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "Earnie Boyd" <earnie_boyd@yahoo.com>
> 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.

Earnie, on 3) I believe we have a terminology problem. gcc -mno-cygwin
changes the _build target_ to mingw32, no the build _environment_.

In the context of configure scripts the build _environment_ is the
platform hosting the running script, and doing the compilation - that is
cygwin.

> > 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.

IMO this is wrong (wrong build value) - see my comment earlier.

Rob


--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

First off... thanks again to both Robert and Earnie for taking part in this
discussion. I appreciate it a lot.

Recapping once again...

Robert says to use:

	$ ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin

	(no need to set CC if i686-pc-mingw32-gcc exists)

Earnie says to use:

	$ ./configure --host=i686-pc-mingw32 --build=i686-pc-mingw32

	(still need to explicitly set CC)

Both of you guys agree that using Cygwin GCC to generate MinGW binaries is
NOT a cross-compile, even though it's a lot like it. Because it's so close,
a cross-compile CAN be EMULATED.

Using Robert's invocation WOULD put configure in cross-compile mode. But
since using Cygwin GCC to generate MinGW is ALMOST like a cross-compile, it
will work out ok. In fact, one compelling reason to use Robert's method is
because one wants the configure script to use the correct build tools, e.g.
cp instead of copy, rm instead of del, etc. I tend to agree that the build
environment IS Cygwin for this very reason.

So here's a question. If configure is put into cross-compile mode (with
Robert's method), then wouldn't it be the case that configure would NOT
execute test binaries? If so, does that hurt the configuration process in
any way? Is this a problem?

If both Earnie's method and Robert's method work, which one is right? Which
method is more likely to break?

Jon

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Robert Collins
> Sent: Saturday, January 12, 2002 3:28 PM
> To: Earnie Boyd; Jon Leichter
> Cc: hschwentner@yahoo.com; cygwin@cygwin.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
> ----- Original Message -----
> From: "Earnie Boyd" <earnie_boyd@yahoo.com>
> > 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.
>
> Earnie, on 3) I believe we have a terminology problem. gcc -mno-cygwin
> changes the _build target_ to mingw32, no the build _environment_.
>
> In the context of configure scripts the build _environment_ is the
> platform hosting the running script, and doing the compilation - that is
> cygwin.
>
> > > 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.
>
> IMO this is wrong (wrong build value) - see my comment earlier.
>
> Rob
>
>
> --
> 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/
>


--
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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "Jon Leichter" <jonleichter@mediaone.net>


> First off... thanks again to both Robert and Earnie for taking part in
this
> discussion. I appreciate it a lot.
>
> Recapping once again...
>
> Robert says to use:
>
> $ ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin
>
> (no need to set CC if i686-pc-mingw32-gcc exists)
>
> Earnie says to use:
>
> $ ./configure --host=i686-pc-mingw32 --build=i686-pc-mingw32
>
> (still need to explicitly set CC)

Both invocations need to explicitly set CC - because of older configure
scripts in the first case.

> Using Robert's invocation WOULD put configure in cross-compile mode.
But
> since using Cygwin GCC to generate MinGW is ALMOST like a
cross-compile, it
> will work out ok. In fact, one compelling reason to use Robert's
method is
> because one wants the configure script to use the correct build tools,
e.g.
> cp instead of copy, rm instead of del, etc. I tend to agree that the
build
> environment IS Cygwin for this very reason.
>
> So here's a question. If configure is put into cross-compile mode
(with
> Robert's method), then wouldn't it be the case that configure would
NOT
> execute test binaries? If so, does that hurt the configuration process
in
> any way? Is this a problem?

Errgle. It _can_ affect the configure process. Say for instance, squid.
Squid uses test binaries to determine socket sizes, maximum fd limits
and the like, which it can't do during a cross compile run, so the cross
compiler (individual) has to provide those on the command line.
Cross-compiling certainly reduces the 'magic' detection that can take
place.

Rob


--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Robert Collins
> Sent: Sunday, January 13, 2002 12:31 PM
> To: Jon Leichter; Earnie Boyd
> Cc: hschwentner@yahoo.com; cygwin@cygwin.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
> ----- Original Message -----
> From: "Jon Leichter" <jonleichter@mediaone.net>
>
> > First off... thanks again to both Robert and Earnie for taking part in
> this
> > discussion. I appreciate it a lot.
> >
> > Recapping once again...
> >
> > Robert says to use:
> >
> > $ ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin
> >
> > (no need to set CC if i686-pc-mingw32-gcc exists)
> >
> > Earnie says to use:
> >
> > $ ./configure --host=i686-pc-mingw32 --build=i686-pc-mingw32
> >
> > (still need to explicitly set CC)
>
> Both invocations need to explicitly set CC - because of older configure
> scripts in the first case.

Yes. I conciously left that part out, trying to only imply the case where
one is using up-to-date autoconf. My fault for being less precise.

> > Using Robert's invocation WOULD put configure in cross-compile mode.
> But
> > since using Cygwin GCC to generate MinGW is ALMOST like a
> cross-compile, it
> > will work out ok. In fact, one compelling reason to use Robert's
> method is
> > because one wants the configure script to use the correct build tools,
> e.g.
> > cp instead of copy, rm instead of del, etc. I tend to agree that the
> build
> > environment IS Cygwin for this very reason.
> >
> > So here's a question. If configure is put into cross-compile mode
> (with
> > Robert's method), then wouldn't it be the case that configure would
> NOT
> > execute test binaries? If so, does that hurt the configuration process
> in
> > any way? Is this a problem?
>
> Errgle. It _can_ affect the configure process. Say for instance, squid.
> Squid uses test binaries to determine socket sizes, maximum fd limits
> and the like, which it can't do during a cross compile run, so the cross
> compiler (individual) has to provide those on the command line.
> Cross-compiling certainly reduces the 'magic' detection that can take
> place.
>
> Rob

Grrr... This makes one start believing that Earnie's method is more correct.
I suppose the right answer to this question is: use whichever method seems
to work best for the project that you're working on. If they both work the
same, then use your favorite one.

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "Jon Leichter" <jonleichter@mediaone.net>

> Grrr... This makes one start believing that Earnie's method is more
correct.
> I suppose the right answer to this question is: use whichever method
seems
> to work best for the project that you're working on. If they both work
the
> same, then use your favorite one.

Exactly :}.

Rob


--
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/

Re: Compiling apps to Mingw32 with cygwin

[Earnie Boyd]

Jon Leichter wrote:
> 
> 
> > > Using Robert's invocation WOULD put configure in cross-compile mode.
> > But
> > > since using Cygwin GCC to generate MinGW is ALMOST like a
> > cross-compile, it
> > > will work out ok. In fact, one compelling reason to use Robert's
> > method is
> > > because one wants the configure script to use the correct build tools,
> > e.g.
> > > cp instead of copy, rm instead of del, etc. I tend to agree that the
> > build
> > > environment IS Cygwin for this very reason.
> > >

You're not going to switch the tools from cp to copy or rm to del by
doing as I suggest.  You would have to buggle (use unnecessary
conditions) the Makefile.in to do that.

> > > So here's a question. If configure is put into cross-compile mode
> > (with
> > > Robert's method), then wouldn't it be the case that configure would
> > NOT
> > > execute test binaries? If so, does that hurt the configuration process
> > in
> > > any way? Is this a problem?
> >
> > Errgle. It _can_ affect the configure process. Say for instance, squid.
> > Squid uses test binaries to determine socket sizes, maximum fd limits
> > and the like, which it can't do during a cross compile run, so the cross
> > compiler (individual) has to provide those on the command line.
> > Cross-compiling certainly reduces the 'magic' detection that can take
> > place.
> >
> > Rob
> 
> Grrr... This makes one start believing that Earnie's method is more correct.

Uhm, yes, that would be the reason not to emulate the cross build.

> I suppose the right answer to this question is: use whichever method seems
> to work best for the project that you're working on. If they both work the
> same, then use your favorite one.
> 

Note, that I think that a _true_ cross build is the more correct way to
build for MinGW using Cygwin.  However, `gcc -mno-cygwin' isn't a _true_
cross compiler so you shouldn't treat it as one.

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/

Re: Compiling apps to Mingw32 with cygwin

[Earnie Boyd]

Robert Collins wrote:
> 
> ----- Original Message -----
> From: "Earnie Boyd" <earnie_boyd@yahoo.com>
> > 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.
> 
> Earnie, on 3) I believe we have a terminology problem. gcc -mno-cygwin
> changes the _build target_ to mingw32, no the build _environment_.
> 
> In the context of configure scripts the build _environment_ is the
> platform hosting the running script, and doing the compilation - that is
> cygwin.
> 

You need to narrow your thinking to GCC and binutils the processes of
consequence.  You only need to specify the triplet because config.guess
guesses wrong based on the value of `uname -s'.  The cygwin binutils as
named will produce executables that use MSVCRT.DLL instead of
CYGWIN1.DLL without having to do anything special with their names or
output.  So, my statement stands based on what happens with GCC, you're
switching the build environment.

> > > 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.
> 
> IMO this is wrong (wrong build value) - see my comment earlier.
> 

No, you're not doing a cross build, therefore I've stated the correct
switches.

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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Earnie Boyd
> Sent: Monday, January 14, 2002 5:43 AM
> To: Robert Collins
> Cc: Jon Leichter; hschwentner@yahoo.com; cygwin@cygwin.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
> You need to narrow your thinking to GCC and binutils the processes of
> consequence.  You only need to specify the triplet because config.guess
> guesses wrong based on the value of `uname -s'.  The cygwin binutils as
> named will produce executables that use MSVCRT.DLL instead of
> CYGWIN1.DLL without having to do anything special with their names or
> output.  So, my statement stands based on what happens with GCC, you're
> switching the build environment.
>

Earnie,

According to GNU documenation, the following utilities are a part of
binutils:

	ar, nm, objcopy, objdump, ranlib, readelf, size, strings,
	strip, c++filt, cxxfilt, nlmconv, windres, dlltool

Which of these utilities "produces executables that use MSVCRT.DLL"? I don't
think any of them do. The binutils package that distributes with Cygwin
(which is what I use) are Cygwin binaries; they are dependent on
CYGWIN1.DLL. They're also all quite happy to operate on MinGW binaries.

GCC, of course, is a suite of tools (the only set, I believe) that generates
MinGW binaries (if, of course, the -mno-cygwin switch is specified). All
Cygwin GCC tools are STILL Cygwin binaries themselves; they all depend on
CYGWIN1.DLL.

I tend to agree with Robert's point of view. It seems to me that the "build"
environment is Cygwin.

In my mind, the only compelling reason NOT to use Cygwin as the "build"
value is because (with an up-to-date autoconf), the configure script would
NOT test executables if it were set to Cygwin. This condition may or may not
hurt the project builder. Thus, it still comes down to whichever build value
works best for the project builder.

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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

===
----- Original Message -----
From: "Jon Leichter" <jonleichter@mediaone.net>

>
> 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:

Reread the thread. I indicated you should have those symlinks. It *may
work* without them, that is different from what *I would do*.

> 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?

gcc -mno-cygwin isn't a cross compile. It links with a different libc,
and puts different headers in the search path - that's all. It *also*
happens to meet the criteria for a cross compile in that
1) cygwin gcc accepts / and \ paths
2) the mingw libraries are present and the file format is understood.
3) The resulting binaries are compatible with the platform.

This is more of an accident than plan :}

Rob


--
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/

Re: Compiling apps to Mingw32 with cygwin

[Earnie Boyd]

> Subject: Re: Compiling apps to Mingw32 with cygwin
> Date: Wed, 9 Jan 2002 18:11:16 +0100
> From: "J. Henning Schwentner" <hschwentner@yahoo.com>
> To: cygwin@cygwin.com
> 
> Am Montag, 7. Januar 2002 17:49 schrieben Sie:
> > Jon Leichter wrote:
> > > - Using CC="gcc -mno-cygwin" is good for compiling, but it's bad for GNU
> > > Libtool, as I have mentioned. I use a wrapper script: CC=mgcc. What do
> > > you think of this Earnie?
> >
> > 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.
> 
> Do the binutils also support the -mno-cygwin switch? 

I'll leave that as an exercise for you to figure out.

> Or can the
> 386-pc-mingw32-<binutilname> files be simple links to the cygwin versions?
> 

Yes, simply symlink will do.

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/

Re: Compiling apps to Mingw32 with cygwin

[Earnie Boyd]

> Subject: RE: Compiling apps to Mingw32 with cygwin
> Date: Sat, 5 Jan 2002 11:35:14 -0800
> From: "Jon Leichter" <jonleichter@mediaone.net>
> Reply-To: "Jon Leichter" <jon@symas.com>
> To: "J. Henning Schwentner" <hschwentner@yahoo.com>
> CC: <cygwin@cygwin.com>
> 
> Hi Henning.
> 
> You can use Cygwin's GCC. It's just a little more involved. Here's a short
> answer. When you configure, do so like this:
> 
>         $ env CC="gcc -mno-cygwin" ./configure --host=i386-pc-mingw32
> 
> Notice that your --host specification was a little off. The way that I have
> specified it is the standard way. If your configure script uses the format
> that you've specified then your format is correct.
> 
> If your configure script uses Libtool, then the above method will not be
> sufficient. Libtool likes to strip the -mno-cygwin switch off at link time.
> For this, I use a wrapper script for MinGW. It's called mgcc, and it looks
> like this:
> 
>         $ cd /usr/bin
>         $ cat > mgcc
>         gcc -mno-cygwin $*
>         ^D
> 
> Now your configure line looks like this:
> 
>         $ env CC=mgcc ./configure --host=i386-pc-mingw32
> 

> Subject: Re: Compiling apps to Mingw32 with cygwin
> Date: Sun, 6 Jan 2002 14:57:23 +0100
> From: "J. Henning Schwentner" <hschwentner@yahoo.com>
> To: <cygwin@cygwin.com>
> 
> Thanks for your quick help, this works nice!
> 
> But, it is a bit difficult. I think ideally configure should detect
> --host=mingw32 --build=cygwin and in this case should add --mno-cygwin to
> CFLAGS and CPPFLAGS (and do something to fix libtool).
> 

Both of these are incorrect and both say the same thing as far as
configure is concerned.  You need to specify the full triplet when using
`gcc -mno-cygwin' as your compiler.  The method used above tells
configure that your cross compiling wanting to build an executable for
i386-pc-mingw32 using i686-pc-cygwin.  Instead you should:

CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' ./configure
--host=i386-pc-mingw32 --build=i386-pc-mingw32 --target=i386-pc-mingw32

OR (if your config.guess and config.sub support it)

CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' ./configure --host=mingw32
--build=mingw32 --target=mingw32

You probably currently see configure scripts check for cross compiling
and end up with a value of `no' because the executable can be executed. 
This method, IIRC, has changed as of autoconf-2.50 which now compares
the values of host and build to determine the value for cross compiling.

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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

Some comments:

- In every configure script I've seen, the build and target variables
receive the value assigned to host if they're not explicitly specified. This
behavior is part of autoconf and not the script writer. Perhaps this is
changing in autoconf 2.50. I don't happen to know those details.

- Building MinGW binaries in a Cygwin environment is kind of like a
cross-compile, and kind of not. I heard enough people take both positions,
so it's seems to have become religious point of view.

- Your specification of CXX is correct if you're project is using C++. I
have not been using C++ in the projects that I built, so I left it out.
Also, since I've never built like that, I didn't think it'd be appropriate
for me to mention it as if I'd know it would work.

- Using CC="gcc -mno-cygwin" is good for compiling, but it's bad for GNU
Libtool, as I have mentioned. I use a wrapper script: CC=mgcc. What do you
think of this Earnie?

Jon

> -----Original Message-----
> From: Earnie Boyd [mailto:earnie_boyd@yahoo.com]
> Sent: Monday, January 07, 2002 6:29 AM
> To: CU List
> Cc: Jon Leichter; J. Henning Schwentner
> Subject: Re: Compiling apps to Mingw32 with cygwin
> >
> > Subject: RE: Compiling apps to Mingw32 with cygwin
> > Date: Sat, 5 Jan 2002 11:35:14 -0800
> > From: "Jon Leichter" <jonleichter@mediaone.net>
> > Reply-To: "Jon Leichter" <jon@symas.com>
> > To: "J. Henning Schwentner" <hschwentner@yahoo.com>
> > CC: <cygwin@cygwin.com>
> >
> > Hi Henning.
> >
> > You can use Cygwin's GCC. It's just a little more involved.
> Here's a short
> > answer. When you configure, do so like this:
> >
> >         $ env CC="gcc -mno-cygwin" ./configure --host=i386-pc-mingw32
> >
> > Notice that your --host specification was a little off. The way
> that I have
> > specified it is the standard way. If your configure script uses
> the format
> > that you've specified then your format is correct.
> >
> > If your configure script uses Libtool, then the above method will not be
> > sufficient. Libtool likes to strip the -mno-cygwin switch off
> at link time.
> > For this, I use a wrapper script for MinGW. It's called mgcc,
> and it looks
> > like this:
> >
> >         $ cd /usr/bin
> >         $ cat > mgcc
> >         gcc -mno-cygwin $*
> >         ^D
> >
> > Now your configure line looks like this:
> >
> >         $ env CC=mgcc ./configure --host=i386-pc-mingw32
> >
>
> > Subject: Re: Compiling apps to Mingw32 with cygwin
> > Date: Sun, 6 Jan 2002 14:57:23 +0100
> > From: "J. Henning Schwentner" <hschwentner@yahoo.com>
> > To: <cygwin@cygwin.com>
> >
> > Thanks for your quick help, this works nice!
> >
> > But, it is a bit difficult. I think ideally configure should detect
> > --host=mingw32 --build=cygwin and in this case should add
> --mno-cygwin to
> > CFLAGS and CPPFLAGS (and do something to fix libtool).
> >
>
> Both of these are incorrect and both say the same thing as far as
> configure is concerned.  You need to specify the full triplet when using
> `gcc -mno-cygwin' as your compiler.  The method used above tells
> configure that your cross compiling wanting to build an executable for
> i386-pc-mingw32 using i686-pc-cygwin.  Instead you should:
>
> CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' ./configure
> --host=i386-pc-mingw32 --build=i386-pc-mingw32 --target=i386-pc-mingw32
>
> OR (if your config.guess and config.sub support it)
>
> CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' ./configure --host=mingw32
> --build=mingw32 --target=mingw32
>
> You probably currently see configure scripts check for cross compiling
> and end up with a value of `no' because the executable can be executed.
> This method, IIRC, has changed as of autoconf-2.50 which now compares
> the values of host and build to determine the value for cross compiling.
>
> 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/

Re: Compiling apps to Mingw32 with cygwin

[Earnie Boyd]

Jon Leichter wrote:
> 
> - Using CC="gcc -mno-cygwin" is good for compiling, but it's bad for GNU
> Libtool, as I have mentioned. I use a wrapper script: CC=mgcc. What do you
> think of this Earnie?
> 

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.

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/

Re: Compiling apps to Mingw32 with cygwin

[J. Henning Schwentner]

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 ...


> 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.

Should'nt these scripts be included in the standard cygwin-gcc- (and 
binutils-) distribution? It would be very easy to include them, and compiling 
for the mingw32 target would also be a lot easier.

-- 
J. Henning Schwentner
Lanthan Software KG

_________________________________________________________
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/

Re: Compiling apps to Mingw32 with cygwin

[J. Henning Schwentner]

Am Montag, 7. Januar 2002 17:49 schrieben Sie:
> Jon Leichter wrote:
> > - Using CC="gcc -mno-cygwin" is good for compiling, but it's bad for GNU
> > Libtool, as I have mentioned. I use a wrapper script: CC=mgcc. What do
> > you think of this Earnie?
>
> 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.

Do the binutils also support the -mno-cygwin switch? Or can the 
386-pc-mingw32-<binutilname> files be simple links to the cygwin versions?


-- 
J. Henning Schwentner
Lanthan Software KG

_________________________________________________________
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

For the most part, I agree with you. Autoconf and Libtool should be fixed.
The motto of the groups seems to be: "patches gratefully accepted". Thus,
unless you, me, or someone else that uses Cygwin GCC for MinGW wants to make
these changes, I wouldn't count on them coming around any time soon.

One other point: AFAIK, the cross-compiling feature of autoconf,
i.e. --host, --build, --target, is not an automated feature. That is, it's
up to the configure.in script writer to use these switches appropriately. I
have ran many configure scripts in the Cygwin environment. I have just about
never seen a configure script use these switches correctly (where
"correctly" is based on the definition of these switches in the autoconf
documentation). Thus, for this issue, you can't look for a "fix" in
autoconf. It's about configure.in script writers doing the right thing.
This, of course, means that there must be a separate "fix" for each project
that is not doing the right thing.

Of course, if a script that you're using is coming out of a OpenSource
project, then again, one is free to supply patches...

Jon

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of J. Henning Schwentner
> Sent: Sunday, January 06, 2002 5:57 AM
> To: cygwin@cygwin.com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
> Thanks for your quick help, this works nice!
>
> But, it is a bit difficult. I think ideally configure should detect
> --host=mingw32 --build=cygwin and in this case should add --mno-cygwin to
> CFLAGS and CPPFLAGS (and do something to fix libtool).
>
> I am not sure if this is a bit off topic, maybe this sould be
> posted to the
> autoconf list.
>
> Regards,
> Henning
>
> _________________________________________________________
> 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/
>


--
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/

RE: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

Hi Henning.

You can use Cygwin's GCC. It's just a little more involved. Here's a short
answer. When you configure, do so like this:

	$ env CC="gcc -mno-cygwin" ./configure --host=i386-pc-mingw32

Notice that your --host specification was a little off. The way that I have
specified it is the standard way. If your configure script uses the format
that you've specified then your format is correct.

If your configure script uses Libtool, then the above method will not be
sufficient. Libtool likes to strip the -mno-cygwin switch off at link time.
For this, I use a wrapper script for MinGW. It's called mgcc, and it looks
like this:

	$ cd /usr/bin
	$ cat > mgcc
	gcc -mno-cygwin $*
	^D

Now your configure line looks like this:

	$ env CC=mgcc ./configure --host=i386-pc-mingw32

There's one more GOTCHA. Cygwin GCC will look in /usr/lib no matter what.
Thus if it finds a library in there that it doesn't find in /usr/lib/mingw,
it will use it. That means when your configure script looks for a library
that MinGW does not support, it believes that you do have it, and it will
try to link it. Most of the time, MinGW does support the libraries that a
configure script is looking for. So you may not have to worry about it.
However, there is a workaround for this too.

I wrote a detailed document on this topic, and it's posted on OpenLDAP's web
site in their FAQ section:

	http://www.openldap.org/faq/data/cache/301.html

It will explain how to fix the last GOTCHA as well...

Jon

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of J. Henning Schwentner
> Sent: Saturday, January 05, 2002 7:42 AM
> To: cygwin@cygwin.com
> Subject: Compiling apps to Mingw32 with cygwin
>
> Hi,
>
> I am trying to compile SDL-1.2.3 for mingw32 with cygwin-1.3.6.
> I use the following steps:
> 	$ ./configure --host=pc-i386-mingw32
> 	# make
>
> It compiles without errors, but the outcoming SDL.dll has references to
> cygwin1.dll not to MSVCRT.dll.
>
> I have also installed Mingw32-1.1. Do I have to use the gcc from the
> mingw-distribution or can I use the cygwin-gcc? If I have to use the
> mingw-gcc, how can I tell this to configure?
>
> Thanks in advance!
>
> Henning
>
> P.S: Please CC me, I am not on the list
>
> --
> J. Henning Schwentner
> Lanthan Software KG
>
> _________________________________________________________
> 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/
>


--
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/

Re: Compiling apps to Mingw32 with cygwin

[J. Henning Schwentner]

Thanks for your quick help, this works nice!

But, it is a bit difficult. I think ideally configure should detect 
--host=mingw32 --build=cygwin and in this case should add --mno-cygwin to 
CFLAGS and CPPFLAGS (and do something to fix libtool).

I am not sure if this is a bit off topic, maybe this sould be posted to the 
autoconf list.

Regards,
Henning

_________________________________________________________
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/

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

----- Original Message -----
From: "J. Henning Schwentner" <hschwentner@yahoo.com>
To: <cygwin@cygwin.com>
Sent: Monday, January 07, 2002 12:57 AM
Subject: Re: Compiling apps to Mingw32 with cygwin


> Thanks for your quick help, this works nice!
>
> But, it is a bit difficult. I think ideally configure should detect
> --host=mingw32 --build=cygwin and in this case should add --mno-cygwin
to
> CFLAGS and CPPFLAGS (and do something to fix libtool).

Why? That would prevent compiling with a cygwin target.
--host and --build and --target are _user_ switches. configure should
never alter those.

As for detecting -mno-cygwin, you can use a variation of the
AC_API_WIN32 Macros' I posted to the autoconf list some time back - but
only do that when you've checked the host platform is actually mingw32.

> I am not sure if this is a bit off topic, maybe this sould be posted
to the
> autoconf list.

It's in the grey area, still related to cygwin, but heading to autoconf
only pretty quickly.

Rob


--
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/

Compiling apps to Mingw32 with cygwin

[J. Henning Schwentner]

Hi,

I am trying to compile SDL-1.2.3 for mingw32 with cygwin-1.3.6.
I use the following steps:
	$ ./configure --host=pc-i386-mingw32
	# make

It compiles without errors, but the outcoming SDL.dll has references to 
cygwin1.dll not to MSVCRT.dll.

I have also installed Mingw32-1.1. Do I have to use the gcc from the 
mingw-distribution or can I use the cygwin-gcc? If I have to use the 
mingw-gcc, how can I tell this to configure?

Thanks in advance!

Henning

P.S: Please CC me, I am not on the list

-- 
J. Henning Schwentner
Lanthan Software KG

_________________________________________________________
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/