Re: Compiling apps to Mingw32 with cygwin

[Earnie Boyd <earnie_boyd@yahoo.com>]

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/