This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Compiling apps to Mingw32 with 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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]