* RE: Compiling apps to Mingw32 with cygwin
@ 2002-01-10 1:39 Bernard Dautrevaux
2002-01-10 13:09 ` Jon Leichter
0 siblings, 1 reply; 52+ messages in thread
From: Bernard Dautrevaux @ 2002-01-10 1:39 UTC (permalink / raw)
To: 'CU List'
> -----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/
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-10 1:39 Compiling apps to Mingw32 with cygwin Bernard Dautrevaux @ 2002-01-10 13:09 ` Jon Leichter 2002-01-10 13:43 ` Robert Collins 2002-01-10 14:31 ` Earnie Boyd 0 siblings, 2 replies; 52+ messages in thread From: Jon Leichter @ 2002-01-10 13:09 UTC (permalink / raw) To: earnie_boyd; +Cc: cygwin, hschwentner 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 13:09 ` Jon Leichter @ 2002-01-10 13:43 ` Robert Collins 2002-01-10 14:05 ` Charles Wilson 2002-01-10 14:06 ` Jon Leichter 2002-01-10 14:31 ` Earnie Boyd 1 sibling, 2 replies; 52+ messages in thread From: Robert Collins @ 2002-01-10 13:43 UTC (permalink / raw) To: cygwin; +Cc: hschwentner ----- 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 13:43 ` Robert Collins @ 2002-01-10 14:05 ` Charles Wilson 2002-01-10 14:06 ` Jon Leichter 1 sibling, 0 replies; 52+ messages in thread From: Charles Wilson @ 2002-01-10 14:05 UTC (permalink / raw) To: Robert Collins; +Cc: cygwin, hschwentner 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-10 13:43 ` Robert Collins 2002-01-10 14:05 ` Charles Wilson @ 2002-01-10 14:06 ` Jon Leichter 2002-01-10 14:29 ` Robert Collins 1 sibling, 1 reply; 52+ messages in thread From: Jon Leichter @ 2002-01-10 14:06 UTC (permalink / raw) To: Robert Collins; +Cc: hschwentner, cygwin > -----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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 14:06 ` Jon Leichter @ 2002-01-10 14:29 ` Robert Collins 2002-01-10 16:25 ` Jon Leichter 0 siblings, 1 reply; 52+ messages in thread From: Robert Collins @ 2002-01-10 14:29 UTC (permalink / raw) To: Jon Leichter; +Cc: hschwentner, 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-10 14:29 ` Robert Collins @ 2002-01-10 16:25 ` Jon Leichter 0 siblings, 0 replies; 52+ messages in thread From: Jon Leichter @ 2002-01-10 16:25 UTC (permalink / raw) To: Robert Collins; +Cc: hschwentner, cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 13:09 ` Jon Leichter 2002-01-10 13:43 ` Robert Collins @ 2002-01-10 14:31 ` Earnie Boyd 2002-01-10 14:40 ` Robert Collins 2002-01-10 16:18 ` Jon Leichter 1 sibling, 2 replies; 52+ messages in thread From: Earnie Boyd @ 2002-01-10 14:31 UTC (permalink / raw) To: Jon Leichter; +Cc: cygwin, hschwentner 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 14:31 ` Earnie Boyd @ 2002-01-10 14:40 ` Robert Collins 2002-01-10 16:18 ` Jon Leichter 1 sibling, 0 replies; 52+ messages in thread From: Robert Collins @ 2002-01-10 14:40 UTC (permalink / raw) To: CU List, Jon Leichter; +Cc: cygwin, hschwentner === ----- 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-10 14:31 ` Earnie Boyd 2002-01-10 14:40 ` Robert Collins @ 2002-01-10 16:18 ` Jon Leichter 2002-01-10 16:28 ` Robert Collins ` (2 more replies) 1 sibling, 3 replies; 52+ messages in thread From: Jon Leichter @ 2002-01-10 16:18 UTC (permalink / raw) To: earnie_boyd; +Cc: hschwentner, cygwin > -----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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 16:18 ` Jon Leichter @ 2002-01-10 16:28 ` Robert Collins 2002-01-10 17:19 ` Jon Leichter 2002-01-10 16:34 ` Charles Wilson 2002-01-11 4:11 ` Earnie Boyd 2 siblings, 1 reply; 52+ messages in thread From: Robert Collins @ 2002-01-10 16:28 UTC (permalink / raw) To: Jon Leichter, earnie_boyd; +Cc: hschwentner, cygwin === ----- 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-10 16:28 ` Robert Collins @ 2002-01-10 17:19 ` Jon Leichter 2002-01-10 17:27 ` Robert Collins 0 siblings, 1 reply; 52+ messages in thread From: Jon Leichter @ 2002-01-10 17:19 UTC (permalink / raw) To: Robert Collins; +Cc: 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? - 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 17:19 ` Jon Leichter @ 2002-01-10 17:27 ` Robert Collins 2002-01-10 17:31 ` Jon Leichter 0 siblings, 1 reply; 52+ messages in thread From: Robert Collins @ 2002-01-10 17:27 UTC (permalink / raw) To: Jon Leichter; +Cc: 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 -- 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-10 17:27 ` Robert Collins @ 2002-01-10 17:31 ` Jon Leichter 2002-01-10 17:44 ` Robert Collins 0 siblings, 1 reply; 52+ messages in thread From: Jon Leichter @ 2002-01-10 17:31 UTC (permalink / raw) To: Robert Collins; +Cc: cygwin > -----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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 17:31 ` Jon Leichter @ 2002-01-10 17:44 ` Robert Collins 2002-01-10 17:50 ` Jon Leichter 0 siblings, 1 reply; 52+ messages in thread From: Robert Collins @ 2002-01-10 17:44 UTC (permalink / raw) To: Jon Leichter; +Cc: 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 -- 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-10 17:44 ` Robert Collins @ 2002-01-10 17:50 ` Jon Leichter 2002-01-10 17:52 ` Robert Collins 0 siblings, 1 reply; 52+ messages in thread From: Jon Leichter @ 2002-01-10 17:50 UTC (permalink / raw) To: Robert Collins; +Cc: cygwin > -----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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 17:50 ` Jon Leichter @ 2002-01-10 17:52 ` Robert Collins 2002-01-10 17:58 ` Christopher Faylor 2002-01-10 18:11 ` Jon Leichter 0 siblings, 2 replies; 52+ messages in thread From: Robert Collins @ 2002-01-10 17:52 UTC (permalink / raw) To: Jon Leichter; +Cc: 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 17:52 ` Robert Collins @ 2002-01-10 17:58 ` Christopher Faylor 2002-01-10 17:59 ` Robert Collins 2002-01-10 18:11 ` Jon Leichter 1 sibling, 1 reply; 52+ messages in thread From: Christopher Faylor @ 2002-01-10 17:58 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 17:58 ` Christopher Faylor @ 2002-01-10 17:59 ` Robert Collins 0 siblings, 0 replies; 52+ messages in thread From: Robert Collins @ 2002-01-10 17:59 UTC (permalink / raw) To: cygwin ----- 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-10 17:52 ` Robert Collins 2002-01-10 17:58 ` Christopher Faylor @ 2002-01-10 18:11 ` Jon Leichter 2002-01-10 18:16 ` Robert Collins 1 sibling, 1 reply; 52+ messages in thread From: Jon Leichter @ 2002-01-10 18:11 UTC (permalink / raw) To: Robert Collins; +Cc: cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 18:11 ` Jon Leichter @ 2002-01-10 18:16 ` Robert Collins 2002-01-10 18:23 ` Jon Leichter 0 siblings, 1 reply; 52+ messages in thread From: Robert Collins @ 2002-01-10 18:16 UTC (permalink / raw) To: Jon Leichter; +Cc: 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. $ 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-10 18:16 ` Robert Collins @ 2002-01-10 18:23 ` Jon Leichter 2002-01-10 18:25 ` Robert Collins 0 siblings, 1 reply; 52+ messages in thread From: Jon Leichter @ 2002-01-10 18:23 UTC (permalink / raw) To: Robert Collins; +Cc: cygwin > -----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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 18:23 ` Jon Leichter @ 2002-01-10 18:25 ` Robert Collins 2002-01-10 18:28 ` Jon Leichter 0 siblings, 1 reply; 52+ messages in thread From: Robert Collins @ 2002-01-10 18:25 UTC (permalink / raw) To: Jon Leichter; +Cc: 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 -- 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-10 18:25 ` Robert Collins @ 2002-01-10 18:28 ` Jon Leichter 0 siblings, 0 replies; 52+ messages in thread From: Jon Leichter @ 2002-01-10 18:28 UTC (permalink / raw) To: Robert Collins; +Cc: cygwin > -----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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 16:18 ` Jon Leichter 2002-01-10 16:28 ` Robert Collins @ 2002-01-10 16:34 ` Charles Wilson 2002-01-11 4:11 ` Earnie Boyd 2 siblings, 0 replies; 52+ messages in thread From: Charles Wilson @ 2002-01-10 16:34 UTC (permalink / raw) To: Jon Leichter; +Cc: earnie_boyd, hschwentner, cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-10 16:18 ` Jon Leichter 2002-01-10 16:28 ` Robert Collins 2002-01-10 16:34 ` Charles Wilson @ 2002-01-11 4:11 ` Earnie Boyd 2002-01-11 10:35 ` Jon Leichter 2 siblings, 1 reply; 52+ messages in thread From: Earnie Boyd @ 2002-01-11 4:11 UTC (permalink / raw) To: Jon Leichter; +Cc: hschwentner, cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-11 4:11 ` Earnie Boyd @ 2002-01-11 10:35 ` Jon Leichter 2002-01-12 12:51 ` Earnie Boyd 2002-01-12 15:27 ` Robert Collins 0 siblings, 2 replies; 52+ messages in thread From: Jon Leichter @ 2002-01-11 10:35 UTC (permalink / raw) To: earnie_boyd, robert.collins; +Cc: hschwentner, cygwin > -----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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-11 10:35 ` Jon Leichter @ 2002-01-12 12:51 ` Earnie Boyd 2002-01-12 15:29 ` Robert Collins 2002-01-12 15:27 ` Robert Collins 1 sibling, 1 reply; 52+ messages in thread From: Earnie Boyd @ 2002-01-12 12:51 UTC (permalink / raw) To: Jon Leichter; +Cc: robert.collins, hschwentner, cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-12 12:51 ` Earnie Boyd @ 2002-01-12 15:29 ` Robert Collins 2002-01-13 10:44 ` Jon Leichter 2002-01-14 5:51 ` Earnie Boyd 0 siblings, 2 replies; 52+ messages in thread From: Robert Collins @ 2002-01-12 15:29 UTC (permalink / raw) To: Earnie Boyd, Jon Leichter; +Cc: hschwentner, 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-12 15:29 ` Robert Collins @ 2002-01-13 10:44 ` Jon Leichter 2002-01-13 12:39 ` Robert Collins 2002-01-14 5:51 ` Earnie Boyd 1 sibling, 1 reply; 52+ messages in thread From: Jon Leichter @ 2002-01-13 10:44 UTC (permalink / raw) To: Robert Collins, Earnie Boyd; +Cc: hschwentner, cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-13 10:44 ` Jon Leichter @ 2002-01-13 12:39 ` Robert Collins 2002-01-13 20:17 ` Jon Leichter 0 siblings, 1 reply; 52+ messages in thread From: Robert Collins @ 2002-01-13 12:39 UTC (permalink / raw) To: Jon Leichter, Earnie Boyd; +Cc: hschwentner, 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. > 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-13 12:39 ` Robert Collins @ 2002-01-13 20:17 ` Jon Leichter 2002-01-14 0:53 ` Robert Collins 2002-01-14 6:09 ` Earnie Boyd 0 siblings, 2 replies; 52+ messages in thread From: Jon Leichter @ 2002-01-13 20:17 UTC (permalink / raw) To: Robert Collins; +Cc: hschwentner, cygwin, Earnie Boyd > -----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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-13 20:17 ` Jon Leichter @ 2002-01-14 0:53 ` Robert Collins 2002-01-14 6:09 ` Earnie Boyd 1 sibling, 0 replies; 52+ messages in thread From: Robert Collins @ 2002-01-14 0:53 UTC (permalink / raw) To: Jon Leichter; +Cc: hschwentner, cygwin, Earnie Boyd ----- 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-13 20:17 ` Jon Leichter 2002-01-14 0:53 ` Robert Collins @ 2002-01-14 6:09 ` Earnie Boyd 1 sibling, 0 replies; 52+ messages in thread From: Earnie Boyd @ 2002-01-14 6:09 UTC (permalink / raw) To: Jon Leichter; +Cc: Robert Collins, hschwentner, cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-12 15:29 ` Robert Collins 2002-01-13 10:44 ` Jon Leichter @ 2002-01-14 5:51 ` Earnie Boyd 2002-01-14 10:48 ` Jon Leichter 1 sibling, 1 reply; 52+ messages in thread From: Earnie Boyd @ 2002-01-14 5:51 UTC (permalink / raw) To: Robert Collins; +Cc: Jon Leichter, hschwentner, cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-14 5:51 ` Earnie Boyd @ 2002-01-14 10:48 ` Jon Leichter 0 siblings, 0 replies; 52+ messages in thread From: Jon Leichter @ 2002-01-14 10:48 UTC (permalink / raw) To: Earnie Boyd; +Cc: hschwentner, cygwin, Robert Collins > -----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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-11 10:35 ` Jon Leichter 2002-01-12 12:51 ` Earnie Boyd @ 2002-01-12 15:27 ` Robert Collins 1 sibling, 0 replies; 52+ messages in thread From: Robert Collins @ 2002-01-12 15:27 UTC (permalink / raw) To: Jon Leichter, earnie_boyd; +Cc: hschwentner, cygwin === ----- 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <3C3EDCA7.C40E3CD6@yahoo.com>]
* Re: Compiling apps to Mingw32 with cygwin [not found] <3C3EDCA7.C40E3CD6@yahoo.com> @ 2002-01-11 5:12 ` Earnie Boyd 2002-01-11 5:33 ` Robert Collins 0 siblings, 1 reply; 52+ messages in thread From: Earnie Boyd @ 2002-01-11 5:12 UTC (permalink / raw) To: CU List > 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-11 5:12 ` Earnie Boyd @ 2002-01-11 5:33 ` Robert Collins 0 siblings, 0 replies; 52+ messages in thread From: Robert Collins @ 2002-01-11 5:33 UTC (permalink / raw) To: Earnie Boyd, CU List === ----- 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <3C3ED90B.F0B81A47@yahoo.com>]
* Re: Compiling apps to Mingw32 with cygwin [not found] <3C3ED90B.F0B81A47@yahoo.com> @ 2002-01-11 4:43 ` Earnie Boyd 0 siblings, 0 replies; 52+ messages in thread From: Earnie Boyd @ 2002-01-11 4:43 UTC (permalink / raw) To: CU List > 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <3C3C999C.E7DBD5CC@yahoo.com>]
* Re: Compiling apps to Mingw32 with cygwin [not found] <3C3C999C.E7DBD5CC@yahoo.com> @ 2002-01-09 11:42 ` Earnie Boyd 0 siblings, 0 replies; 52+ messages in thread From: Earnie Boyd @ 2002-01-09 11:42 UTC (permalink / raw) To: CU List > 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <3C391A0A.758D073@yahoo.com>]
* Re: Compiling apps to Mingw32 with cygwin [not found] <3C391A0A.758D073@yahoo.com> @ 2002-01-07 6:29 ` Earnie Boyd 2002-01-07 8:34 ` Jon Leichter 0 siblings, 1 reply; 52+ messages in thread From: Earnie Boyd @ 2002-01-07 6:29 UTC (permalink / raw) To: CU List; +Cc: Jon Leichter, J. Henning Schwentner > 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin 2002-01-07 6:29 ` Earnie Boyd @ 2002-01-07 8:34 ` Jon Leichter 2002-01-07 8:49 ` Earnie Boyd 0 siblings, 1 reply; 52+ messages in thread From: Jon Leichter @ 2002-01-07 8:34 UTC (permalink / raw) To: earnie_boyd; +Cc: J. Henning Schwentner, CU List 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-07 8:34 ` Jon Leichter @ 2002-01-07 8:49 ` Earnie Boyd 2002-01-07 11:44 ` J. Henning Schwentner 2002-01-09 9:09 ` J. Henning Schwentner 0 siblings, 2 replies; 52+ messages in thread From: Earnie Boyd @ 2002-01-07 8:49 UTC (permalink / raw) To: Jon Leichter; +Cc: J. Henning Schwentner, CU List 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-07 8:49 ` Earnie Boyd @ 2002-01-07 11:44 ` J. Henning Schwentner 2002-01-09 9:09 ` J. Henning Schwentner 1 sibling, 0 replies; 52+ messages in thread From: J. Henning Schwentner @ 2002-01-07 11:44 UTC (permalink / raw) To: Cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-07 8:49 ` Earnie Boyd 2002-01-07 11:44 ` J. Henning Schwentner @ 2002-01-09 9:09 ` J. Henning Schwentner 1 sibling, 0 replies; 52+ messages in thread From: J. Henning Schwentner @ 2002-01-09 9:09 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: Compiling apps to Mingw32 with cygwin
@ 2002-01-07 6:24 Bernard Dautrevaux
0 siblings, 0 replies; 52+ messages in thread
From: Bernard Dautrevaux @ 2002-01-07 6:24 UTC (permalink / raw)
To: 'J. Henning Schwentner', cygwin
> -----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/
^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <200201061357.IAA27856@zealous.cnchost.com>]
* RE: Compiling apps to Mingw32 with cygwin [not found] <200201061357.IAA27856@zealous.cnchost.com> @ 2002-01-06 9:55 ` Jon Leichter 0 siblings, 0 replies; 52+ messages in thread From: Jon Leichter @ 2002-01-06 9:55 UTC (permalink / raw) To: J. Henning Schwentner; +Cc: cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <200201051541.KAA10021@irresistable.cnchost.com>]
* RE: Compiling apps to Mingw32 with cygwin [not found] <200201051541.KAA10021@irresistable.cnchost.com> @ 2002-01-05 11:38 ` Jon Leichter 2002-01-06 5:55 ` J. Henning Schwentner [not found] ` <ITDOMAIN003sl3xbYiM0000006c@itdomain003.itdomain.net.au> 0 siblings, 2 replies; 52+ messages in thread From: Jon Leichter @ 2002-01-05 11:38 UTC (permalink / raw) To: J. Henning Schwentner; +Cc: cygwin 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Compiling apps to Mingw32 with cygwin 2002-01-05 11:38 ` Jon Leichter @ 2002-01-06 5:55 ` J. Henning Schwentner [not found] ` <ITDOMAIN003sl3xbYiM0000006c@itdomain003.itdomain.net.au> 1 sibling, 0 replies; 52+ messages in thread From: J. Henning Schwentner @ 2002-01-06 5:55 UTC (permalink / raw) To: 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <ITDOMAIN003sl3xbYiM0000006c@itdomain003.itdomain.net.au>]
* Re: Compiling apps to Mingw32 with cygwin [not found] ` <ITDOMAIN003sl3xbYiM0000006c@itdomain003.itdomain.net.au> @ 2002-01-06 13:47 ` Robert Collins 0 siblings, 0 replies; 52+ messages in thread From: Robert Collins @ 2002-01-06 13:47 UTC (permalink / raw) To: J. Henning Schwentner, cygwin ----- 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Compiling apps to Mingw32 with cygwin @ 2002-01-05 7:40 J. Henning Schwentner 0 siblings, 0 replies; 52+ messages in thread From: J. Henning Schwentner @ 2002-01-05 7:40 UTC (permalink / raw) To: 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/ ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2002-01-14 18:27 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-01-10 1:39 Compiling apps to Mingw32 with cygwin Bernard Dautrevaux 2002-01-10 13:09 ` Jon Leichter 2002-01-10 13:43 ` Robert Collins 2002-01-10 14:05 ` Charles Wilson 2002-01-10 14:06 ` Jon Leichter 2002-01-10 14:29 ` Robert Collins 2002-01-10 16:25 ` Jon Leichter 2002-01-10 14:31 ` Earnie Boyd 2002-01-10 14:40 ` Robert Collins 2002-01-10 16:18 ` Jon Leichter 2002-01-10 16:28 ` Robert Collins 2002-01-10 17:19 ` Jon Leichter 2002-01-10 17:27 ` Robert Collins 2002-01-10 17:31 ` Jon Leichter 2002-01-10 17:44 ` Robert Collins 2002-01-10 17:50 ` Jon Leichter 2002-01-10 17:52 ` Robert Collins 2002-01-10 17:58 ` Christopher Faylor 2002-01-10 17:59 ` Robert Collins 2002-01-10 18:11 ` Jon Leichter 2002-01-10 18:16 ` Robert Collins 2002-01-10 18:23 ` Jon Leichter 2002-01-10 18:25 ` Robert Collins 2002-01-10 18:28 ` Jon Leichter 2002-01-10 16:34 ` Charles Wilson 2002-01-11 4:11 ` Earnie Boyd 2002-01-11 10:35 ` Jon Leichter 2002-01-12 12:51 ` Earnie Boyd 2002-01-12 15:29 ` Robert Collins 2002-01-13 10:44 ` Jon Leichter 2002-01-13 12:39 ` Robert Collins 2002-01-13 20:17 ` Jon Leichter 2002-01-14 0:53 ` Robert Collins 2002-01-14 6:09 ` Earnie Boyd 2002-01-14 5:51 ` Earnie Boyd 2002-01-14 10:48 ` Jon Leichter 2002-01-12 15:27 ` Robert Collins [not found] <3C3EDCA7.C40E3CD6@yahoo.com> 2002-01-11 5:12 ` Earnie Boyd 2002-01-11 5:33 ` Robert Collins [not found] <3C3ED90B.F0B81A47@yahoo.com> 2002-01-11 4:43 ` Earnie Boyd [not found] <3C3C999C.E7DBD5CC@yahoo.com> 2002-01-09 11:42 ` Earnie Boyd [not found] <3C391A0A.758D073@yahoo.com> 2002-01-07 6:29 ` Earnie Boyd 2002-01-07 8:34 ` Jon Leichter 2002-01-07 8:49 ` Earnie Boyd 2002-01-07 11:44 ` J. Henning Schwentner 2002-01-09 9:09 ` J. Henning Schwentner -- strict thread matches above, loose matches on Subject: below -- 2002-01-07 6:24 Bernard Dautrevaux [not found] <200201061357.IAA27856@zealous.cnchost.com> 2002-01-06 9:55 ` Jon Leichter [not found] <200201051541.KAA10021@irresistable.cnchost.com> 2002-01-05 11:38 ` Jon Leichter 2002-01-06 5:55 ` J. Henning Schwentner [not found] ` <ITDOMAIN003sl3xbYiM0000006c@itdomain003.itdomain.net.au> 2002-01-06 13:47 ` Robert Collins 2002-01-05 7:40 J. Henning Schwentner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).