Re: Compiling apps to Mingw32 with cygwin
Robert Collins wrote: - Original Message - From: Earnie Boyd [EMAIL PROTECTED] 1) `gcc -mno-cygwin' is not a cross compile. 2) it is possible to emulate a cross build system using a scripted `gcc -mno-cygwin' and symlinks. 3) `gcc -mno-cygwin' switches the build environment from Cygwin to MinGW. Earnie, on 3) I believe we have a terminology problem. gcc -mno-cygwin changes the _build target_ to mingw32, no the build _environment_. In the context of configure scripts the build _environment_ is the platform hosting the running script, and doing the compilation - that is cygwin. You need to narrow your thinking to GCC and binutils the processes of consequence. You only need to specify the triplet because config.guess guesses wrong based on the value of `uname -s'. The cygwin binutils as named will produce executables that use MSVCRT.DLL instead of CYGWIN1.DLL without having to do anything special with their names or output. So, my statement stands based on what happens with GCC, you're switching the build environment. You said this was wrong. To be consisent with future behavior, it seems that I must specify build. So if you're suggesting that I'm not cross-compiling, then it would be: $ env CC=mgcc ./configure --host=i686-pc-mingw32 --build=i686-pc-mingw32 This is what I would do. IMO this is wrong (wrong build value) - see my comment earlier. No, you're not doing a cross build, therefore I've stated the correct switches. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
Jon Leichter wrote: Using Robert's invocation WOULD put configure in cross-compile mode. But since using Cygwin GCC to generate MinGW is ALMOST like a cross-compile, it will work out ok. In fact, one compelling reason to use Robert's method is because one wants the configure script to use the correct build tools, e.g. cp instead of copy, rm instead of del, etc. I tend to agree that the build environment IS Cygwin for this very reason. You're not going to switch the tools from cp to copy or rm to del by doing as I suggest. You would have to buggle (use unnecessary conditions) the Makefile.in to do that. So here's a question. If configure is put into cross-compile mode (with Robert's method), then wouldn't it be the case that configure would NOT execute test binaries? If so, does that hurt the configuration process in any way? Is this a problem? Errgle. It _can_ affect the configure process. Say for instance, squid. Squid uses test binaries to determine socket sizes, maximum fd limits and the like, which it can't do during a cross compile run, so the cross compiler (individual) has to provide those on the command line. Cross-compiling certainly reduces the 'magic' detection that can take place. Rob Grrr... This makes one start believing that Earnie's method is more correct. Uhm, yes, that would be the reason not to emulate the cross build. I suppose the right answer to this question is: use whichever method seems to work best for the project that you're working on. If they both work the same, then use your favorite one. Note, that I think that a _true_ cross build is the more correct way to build for MinGW using Cygwin. However, `gcc -mno-cygwin' isn't a _true_ cross compiler so you shouldn't treat it as one. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Earnie Boyd Sent: Monday, January 14, 2002 5:43 AM To: Robert Collins Cc: Jon Leichter; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Compiling apps to Mingw32 with cygwin You need to narrow your thinking to GCC and binutils the processes of consequence. You only need to specify the triplet because config.guess guesses wrong based on the value of `uname -s'. The cygwin binutils as named will produce executables that use MSVCRT.DLL instead of CYGWIN1.DLL without having to do anything special with their names or output. So, my statement stands based on what happens with GCC, you're switching the build environment. Earnie, According to GNU documenation, the following utilities are a part of binutils: ar, nm, objcopy, objdump, ranlib, readelf, size, strings, strip, c++filt, cxxfilt, nlmconv, windres, dlltool Which of these utilities produces executables that use MSVCRT.DLL? I don't think any of them do. The binutils package that distributes with Cygwin (which is what I use) are Cygwin binaries; they are dependent on CYGWIN1.DLL. They're also all quite happy to operate on MinGW binaries. GCC, of course, is a suite of tools (the only set, I believe) that generates MinGW binaries (if, of course, the -mno-cygwin switch is specified). All Cygwin GCC tools are STILL Cygwin binaries themselves; they all depend on CYGWIN1.DLL. I tend to agree with Robert's point of view. It seems to me that the build environment is Cygwin. In my mind, the only compelling reason NOT to use Cygwin as the build value is because (with an up-to-date autoconf), the configure script would NOT test executables if it were set to Cygwin. This condition may or may not hurt the project builder. Thus, it still comes down to whichever build value works best for the project builder. Jon -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins Sent: Saturday, January 12, 2002 3:28 PM To: Earnie Boyd; Jon Leichter Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Compiling apps to Mingw32 with cygwin - Original Message - From: Earnie Boyd [EMAIL PROTECTED] 1) `gcc -mno-cygwin' is not a cross compile. 2) it is possible to emulate a cross build system using a scripted `gcc -mno-cygwin' and symlinks. 3) `gcc -mno-cygwin' switches the build environment from Cygwin to MinGW. Earnie, on 3) I believe we have a terminology problem. gcc -mno-cygwin changes the _build target_ to mingw32, no the build _environment_. In the context of configure scripts the build _environment_ is the platform hosting the running script, and doing the compilation - that is cygwin. You said this was wrong. To be consisent with future behavior, it seems that I must specify build. So if you're suggesting that I'm not cross-compiling, then it would be: $ env CC=mgcc ./configure --host=i686-pc-mingw32 --build=i686-pc-mingw32 This is what I would do. IMO this is wrong (wrong build value) - see my comment earlier. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
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
Re: Compiling apps to Mingw32 with cygwin
=== - Original Message - From: Jon Leichter [EMAIL PROTECTED] Earnie and Robert, I'm a bit confused when I consider the commentary that you both have contributed on this topic. Here's what I have assessed. You two guys correct me where I'm wrong. === Robert has implied that using GCC with -mno-cygwin is virtually a cross-compile and should be treated as such. An up-to-date and well written configure script would require that the user have i686-pc-mingw32-gcc (which as a script or a binary invokes gcc -mno-cygwin). He would not necessarily need to symlink other binutils to i686-pc-mingw32-tool because the configure script would find the build (Cygwin) tools after checking for the host tools. He would invoke configure with the following: Reread the thread. I indicated you should have those symlinks. It *may work* without them, that is different from what *I would do*. Earnie. Your comments seem to contradict each other. In your last email, it seems you are implying that gcc -mno-cygwin is NOT a cross-compile. And then you went on to explain how I could safely use the switches if I set symlinks to emulate a cross-compile. Which point of view do you support Earnie? gcc -mno-cygwin isn't a cross compile. It links with a different libc, and puts different headers in the search path - that's all. It *also* happens to meet the criteria for a cross compile in that 1) cygwin gcc accepts / and \ paths 2) the mingw libraries are present and the file format is understood. 3) The resulting binaries are compatible with the platform. This is more of an accident than plan :} Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
- Original Message - From: Earnie Boyd [EMAIL PROTECTED] 1) `gcc -mno-cygwin' is not a cross compile. 2) it is possible to emulate a cross build system using a scripted `gcc -mno-cygwin' and symlinks. 3) `gcc -mno-cygwin' switches the build environment from Cygwin to MinGW. Earnie, on 3) I believe we have a terminology problem. gcc -mno-cygwin changes the _build target_ to mingw32, no the build _environment_. In the context of configure scripts the build _environment_ is the platform hosting the running script, and doing the compilation - that is cygwin. You said this was wrong. To be consisent with future behavior, it seems that I must specify build. So if you're suggesting that I'm not cross-compiling, then it would be: $ env CC=mgcc ./configure --host=i686-pc-mingw32 --build=i686-pc-mingw32 This is what I would do. IMO this is wrong (wrong build value) - see my comment earlier. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
Jon Leichter wrote:
-Original Message-
From: Earnie Boyd [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 10, 2002 2:31 PM
To: Jon Leichter
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Compiling apps to Mingw32 with cygwin
Using `gcc -mno-cygwin' is switching the build environment to MinGW. It
says use the headers in /usr/include/mingw instead of /usr/include and
to use the libraries in /usr/lib/mingw instead of the ones in /usr/lib.
Thus you're switching the build environment to MinGW.
I already understand the implications of using the -mno-cygwin switch. To be
more precise, -mno-cygwin does NOT tell GCC to use /usr/lib/mingw INSTEAD of
the ones in /usr/lib. GCC, by generic default, will ALWAYS look in /usr/lib
if it doesn't find the libraries it's looking for elsewhere. I recently
posted a topic about this.
The key to our lack of agreement is terminology, perhaps due to me. I
understand that the -mno-cygwin switch causes Cygwin-GCC to generate MinGW
binaries, but the switch is actually driven by the specs file. Cygwin-GCC is
still a Cygwin binary. All other tools are still Cygwin binaries. I am not
so sure that warrants the phrase MinGW build environment. It seems to me
that I'm still using a Cygwin build environment to generate MinGW binaries.
Not in the sense of what the build environment means to
AC_CANONICAL_SYSTEM, in those terms you are switching the build
environment. If you were using a true cross build system for MinGW
then, yes you would be correct. Since `gcc -mno-cygwin' isn't a true
cross build system then you're not correct. The -mno-cygwin switch
changes the build environment from Cygwin to MinGW.
In his last email on this topic, Robert Collins confirmed for me that it
would be appropriate to specify --build=i686-pc-cygwin
and --host=i686-pc-mingw32. (I've intentionally left --target out since it's
not pertinent to this part of the discussion).
And if `gcc -mno-cygwin' where a true cross build system then yes it
apples. However, it's not and the -mno-cygwin changes the build
environment to mingw32.
The symlink approach (i.e. i386-pc-mingw32-gcc) might be appropriate for
No, the poster has a wrapper script he named mgcc. The symlink was for
binutils binaries.
Actually, it was me (not the poster) that has an mgcc wrapper script. I
was the one who suggested it.
I still don't understand why I'd want to symlink the binutils binaries. I
WANT the Cygwin binutils. They don't generate object code; they operate on
it. The Cygwin binutils do a fine job (as Cygwin binaries) operating on
MinGW binaries. I've never had a problem.
To emulate the cross build system. Then you could safely use the
switches as you desire.
latter versions of autoconf, but it does not work for earlier
versions. I
contribute to the OpenLDAP project, specifically its MinGW
support. To build
MinGW OpenLDAP, I've also got to build regex-0.12, gdbm-1.8.0, and
libtool-1.4.2. As far as I can tell, none of the configure
scripts in these
projects conform to the notion of looking for ${host}-gcc or any other
${host}-tool. In these projects, the solution I pointed out works
flawlessly:
CC=mgcc ./configure --host=i686-pc-mingw32
Not all configure.in contains AC_CANONICAL_SYSTEM. Try ones that do.
E.G.: binutils, gcc.
I understand that configure.in scripts written properly or in a standard
manner will make proper use of --host, --build, and --target. My point is
that not all projects do use it properly. It still requires that the project
builder be aware. Without awareness, more and more people will post to
mailing lists stating: Hey, I used these switches as documented in
Autoconf, and it didn't work right.
Which should mean that the maintainer of the package at least get a bug
fix report with patch so that the next release has it corrected.
Earnie.
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
Subject: Re: Compiling apps to Mingw32 with cygwin Date: Fri, 11 Jan 2002 13:25:17 +1100 From: Robert Collins [EMAIL PROTECTED] To: Jon Leichter [EMAIL PROTECTED] CC: [EMAIL PROTECTED] - Original Message - From: Jon Leichter [EMAIL PROTECTED] See above why it doesn't. mingw != cygwin :}. If 'build' WERE to be tested automatically, independent to 'host', it would come up with 'i686-pc-cygwin'. Thus, we'd effectively end up with the same line you specified above. So that does work, right? Or are you trying to confuse me again??? :) What doesn't kill us makes us stronger. IF build were tested correctly yes. But it's not currently tested - it defaults to host IFF host is defined. This rule is changed for 2.50 and greater. Build no longer takes on the value of host and you're warned about this when specifying --host without specifying --build. IIRC, if you specify build without host then host takes on the value of build but I may be wrong on this point. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
=== - Original Message - From: Earnie Boyd [EMAIL PROTECTED] This rule is changed for 2.50 and greater. Build no longer takes on the value of host and you're warned about this when specifying --host without specifying --build. IIRC, if you specify build without host then host takes on the value of build but I may be wrong on this point. The autoconf 2.5 manual specifies that build takes on the value of host AND that a warning is generated. I've also checked the generated macros, and that is the behaviour. I too thought that the build was checked if --host was specified but build omited in 2.5 which is why I investigated. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
-Original Message- From: Earnie Boyd [mailto:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
Earnie Boyd wrote:
Your wrapper script is a good idea but has the wrong name as has been
pointed out already. It needs to be named i386-pc-mingw32-gcc and a
copy as mingw32-gcc so that when specifying the --host=mingw32 or
--host=i386-pc-mingw32 the configure script will find it appropriately.
Of course to do this you also need to do the same for the binutils
binaries.
Yes, specifying --host without the other parts of the triplet indicates
a cross build to configure. You are even warned of this fact. Specify
all three to avoid configure from figuring it out on it's own. You've
just been lucky enough to not configure a package that cares. Try
configuring binutils if you want to see what happens with just
specifying host.
J. Henning Schwentner wrote:
Dear Earnie,
I do not get it with the --build switch. Am I not building on
i686-pc-cygwin? Is it i368-pc-mingw because I use the mingw-headers?
But I use the cygwin-compiler.
Sorry, but I am confused a bit ...
Earnie, I'm confused too.
The symlink approach (i.e. i386-pc-mingw32-gcc) might be appropriate for
latter versions of autoconf, but it does not work for earlier versions. I
contribute to the OpenLDAP project, specifically its MinGW support. To build
MinGW OpenLDAP, I've also got to build regex-0.12, gdbm-1.8.0, and
libtool-1.4.2. As far as I can tell, none of the configure scripts in these
projects conform to the notion of looking for ${host}-gcc or any other
${host}-tool. In these projects, the solution I pointed out works
flawlessly:
CC=mgcc ./configure --host=i686-pc-mingw32
The configure script in regex-0.12 does not even accept the --host switch
(or --target or --build). Instead, it treats the last parameter on the
command line as the host:
CC=mgcc ./configure i686-pc-mingw32
The configure script in regex-0.12 does not make any real use of this value,
so it doesn't really have any effect on the build.
I originally responded to J. Henning Schwentner, who started this thread. At
this point, I don't remember what he said he was building. However, it's
obvious to me that unless you're building a project with a configure script
built by an up-to-date version of autoconf, none of what you have suggested
will work. Note that the approach I suggested will work in either case, WITH
THE POSSIBLE EXCEPTION (as you have stated) that one runs into trouble
if --build and --target are not specified as well.
This spawns another associated topic. What are the right values for the
triplets (in CURRENT autoconf)? If you're building MinGW binaries in a
Cygwin-hosted environment, it seems to me that you should ONLY
specify --target=i686-pc-mingw32 and let the other two switches resolve
themselves to i686-pc-cygwin. When I build MinGW binaries with Cygwin tools,
I am not using a MinGW-hosted environment or MinGW tools. All of binutils,
for example, are still Cygwin tools, and they DON'T honor the -mno-cygwin
switch. I don't want to symlink those tools either. None of this should
matter as long as GCC produces MinGW binaries. Why should it matter if
configure believes that you're doing a cross-compile. In a loose sense, you
are. This, of course, is a religious argument.
Note that I have tried to only use the --target switch in my projects,
opposed to the --host switch. However, in OpenLDAP and the other related
projects, NONE of the configure scripts handle these switches correctly. I
found that using --host was the best solution for these projects.
Indeed, until the latest version of autoconf makes its way into all projects
as a standard, these switches will need to be examined by the project
builder in order to have context on how to build.
Jon
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins Sent: Thursday, January 10, 2002 1:44 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Compiling apps to Mingw32 with cygwin Autoconf 2.13 supports these options - so the configure script doesn't need to be *that* up to date. However, the script needs AC_CANONICAL_BUILD AC_CANONICAL_HOST (and if the package generates platform specific output (ie it's an assembler/compiler etc) AC_CANONICAL_TARGET in the configure.in. You may need to add the relevant macros and run autoconf again. As for --build, it is automatically detected as long as AC_CANONICAL_BUILD is in the script. You may get a warning == configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. == This warning is safe IFF you have a cross compiler. Ok. Definitely some misunderstandings on my part. So, I will restate: For any particular project, the --build, --host, --target switches are not guaranteed to be work properly. This will depend on how well configure.in has been written. In that respect, the project builder STILL needs to manually check the 'configure' script (or just try to use it and see what happens). This spawns another associated topic. What are the right values for the triplets (in CURRENT autoconf)? If you're building MinGW binaries in a Cygwin-hosted environment, it seems to me that you should ONLY specify --target=i686-pc-mingw32 and let the other two switches resolve. No. Specify --host. The meaning is clearly documented in the autoconf documentation. For clarity: build - what OS the compilation is running on.. host - what OS the binaries created should run on. target - what OS the binaries created should target their output to. Actually, I'm a little unclear. Are you saying that 'target' is for binaries that you build, which in themselves, generate other binaries? Would an example of this be GCC? Would I still need to properly specify --target if I wasn't building binaries that generated binaries? Would you then say that the following is the appropriate set of switches for Cygwin-GCC to produce MinGW binaries: --build=i686-pc-cygwin --host=i686-pc-mingw32 --target=i686-pc-mingw32 Can I leave out the --build switch? Will it get automatically resolved? Or does that ALSO depend on how well configure.in was written? In the configure scripts I've used, I have consistently seen the 'build' variables get assigned the same values as the 'host' variables. Note that I have tried to only use the --target switch in my projects, opposed to the --host switch. However, in OpenLDAP and the other related projects, NONE of the configure scripts handle these switches correctly. I found that using --host was the best solution for these projects. --target being the wrong switch, I'm not surprised it didn't do what you wanted :}. Ok. Once I've had my switch questions answered, I will go back and see how well those switches play in my projects. Jon -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
- Original Message - From: Jon Leichter [EMAIL PROTECTED] No. Specify --host. The meaning is clearly documented in the autoconf documentation. For clarity: build - what OS the compilation is running on.. host - what OS the binaries created should run on. target - what OS the binaries created should target their output to. Actually, I'm a little unclear. Are you saying that 'target' is for binaries that you build, which in themselves, generate other binaries? Would an example of this be GCC? Yes. The way they are used is kinda cool. Imagine that you've got a new platform (say wince). It's got no gcc at the moment, and the c compiler you've got for it is brain-dead (can't host a two-stage gcc build). You do have a C library that should build for it. What you do is: build gcc+binutils with --build=here --host=here --target=wince and then build the C library for that platform. Place those libraries in an appropriate search location (ie /usr/local/lib/wince :}) then you build gcc+binutils with --build=here --host=wince --target=wince and then you copy the resulting binaries to the target platform, and finally can build gcc as a native 3 step boot strap, to ensure everything is ok. i.e. (for completeness) build gcc+binutils with --build=wince --host=wince --target=wince Would I still need to properly specify --target if I wasn't building binaries that generated binaries? Would you then say that the following is the appropriate set of switches for Cygwin-GCC to produce MinGW binaries: Target can be safely skipped if you know for sure that the package does not create platform specific output. I'm not saying 'binaries' here because there are other forms of platform specific output that may exist. --build=i686-pc-cygwin --host=i686-pc-mingw32 --target=i686-pc-mingw32 Yes, that should work. GCC will look for a i686-pc-mingw32 cross compiler. Can I leave out the --build switch? Will it get automatically resolved? Or Thats what I said :}. I was wrong (I've just rechecked). In theory I'm right, but for backward compatability, if you specify host, but not build, then build is set to host. This is (obviously) wrong and will eventually get removed. For now specify both build and host explicitly. (which is a bummer for cross- scripts (because the user must then know what build is, or the script must duplicate what config.guess and config.sub do.). does that ALSO depend on how well configure.in was written? In the configure scripts I've used, I have consistently seen the 'build' variables get assigned the same values as the 'host' variables. You've seen broken scripts then. There may well be brain damaged scripts around. See http://www.gnu.org/manual/autoconf/html_mono/autoconf.html#SEC117 Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
Jon Leichter 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
Re: Compiling apps to Mingw32 with cygwin
=== - Original Message - From: Earnie Boyd [EMAIL PROTECTED] My statements are based on the standard. For those packages conforming to AC_CAN0NICAL_SYSTEM my statements will make a difference. I'm saying you should just get used to always doing it that way so that you never have a problem. Fine if you don't, you will find the package that needs it. BTW: According to http://www.gnu.org/manual/autoconf/html_mono/autoconf.html#SEC144 AC_CANONICAL_SYSTEM is obsolete. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
-Original Message-
From: Earnie Boyd [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 10, 2002 2:31 PM
To: Jon Leichter
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
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
Re: Compiling apps to Mingw32 with cygwin
=== - Original Message - From: Jon Leichter [EMAIL PROTECTED] I still don't understand why I'd want to symlink the binutils binaries. I WANT the Cygwin binutils. They don't generate object code; they operate on it. The Cygwin binutils do a fine job (as Cygwin binaries) operating on MinGW binaries. I've never had a problem. Because when autoconf is cross compiling (that is, when _host_!=_build_) it looks for compilers and binutils utilities named with a prefix of the _target_ they where built for. IOW when you configure foo with --build=i686-pc-cygwin --host=i686-pc-mingw32 autoconf looks for gcc and binutils created via: configure --build=wherever --host=i686-pc-cygwin --target=i686-pc-mingw3 2 (note that the gcc/binutil HOST is == to the foo BUILD). Those gc+binutils files get named with a prefix == the target they arebuilt for (that is i686-pc-mingw32). Now the cygwin standard gcc and binutils (which are prefixed with i686-pc-cygwin can happily generate mingw32 code, so the symlink i686-pc-mingw32 lets autoconf find what it expects. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
Jon Leichter 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 [EMAIL PROTECTED] and [EMAIL PROTECTED] aren't interested, we can at least add them to cygwin's gdbm if they provide important bugfixes... --Chuck cygwin gdbm maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
Ok. I need to return to asking some questions with my new understanding
of --build, --host, and --target (which I'm incredibly grateful for and
happy about).
I have returned to working with OpenLDAP. The configure script is generated
with autconf-2.13.1. It uses AC_CANONICAL_SYSTEM, which you say is
deprecated. I assume, however, that it still works to some extent.
I tried to configure with the following:
$ ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32
I've left --target off, since I know it will get the value of --host, which
is what I want. It does.
First, some questions:
- What is correct: i386-pc-mingw32 or i686-pc-mingw32? If one is correct,
why? If both are correct, how does one decide which one to use?
- I notice that if I merely use --host=mingw32, config.guess will equate
mingw32 as i386-unknown-mingw32. Why?
- Is there a plan to get 32 from mingw32, i.e. mingw? Of course, that
won't be useful with old projects that still need the 32 to be present...
:(
===
Now my results:
- I never see configure look for i686-pc-mingw32-gcc. It merely picks up
'gcc'. Any ideas why?
- I DO see configure look for ${host} binutils, i.e. i686-pc-mingw32-tool,
but since I don't have symlinks, it finds unprefixed versions of the tools.
This, of course, is what I want to happen.
Jon
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
- Original Message - From: Jon Leichter [EMAIL PROTECTED] To: Robert Collins [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 12:20 PM Subject: RE: Compiling apps to Mingw32 with cygwin Ok. I need to return to asking some questions with my new understanding of --build, --host, and --target (which I'm incredibly grateful for and happy about). I have returned to working with OpenLDAP. The configure script is generated with autconf-2.13.1. It uses AC_CANONICAL_SYSTEM, which you say is deprecated. I assume, however, that it still works to some extent. I tried to configure with the following: $ ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 I've left --target off, since I know it will get the value of --host, which is what I want. It does. First, some questions: - What is correct: i386-pc-mingw32 or i686-pc-mingw32? If one is correct, why? If both are correct, how does one decide which one to use? - I notice that if I merely use --host=mingw32, config.guess will equate mingw32 as i386-unknown-mingw32. Why? - Is there a plan to get 32 from mingw32, i.e. mingw? Of course, that won't be useful with old projects that still need the 32 to be present... :( === Now my results: - I never see configure look for i686-pc-mingw32-gcc. It merely picks up 'gcc'. Any ideas why? Do you have an accessible i686-pc-mingw32-gcc ? have a look at the configure script - it may provide some clues :}. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
-Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 10, 2002 5:27 PM To: Jon Leichter Cc: [EMAIL PROTECTED] Subject: Re: Compiling apps to Mingw32 with cygwin - Original Message - From: Jon Leichter [EMAIL PROTECTED] To: Robert Collins [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 12:20 PM Subject: RE: Compiling apps to Mingw32 with cygwin Ok. I need to return to asking some questions with my new understanding of --build, --host, and --target (which I'm incredibly grateful for and happy about). I have returned to working with OpenLDAP. The configure script is generated with autconf-2.13.1. It uses AC_CANONICAL_SYSTEM, which you say is deprecated. I assume, however, that it still works to some extent. I tried to configure with the following: $ ./configure --build=i686-pc-cygwin --host=i686-pc-mingw32 I've left --target off, since I know it will get the value of --host, which is what I want. It does. First, some questions: - What is correct: i386-pc-mingw32 or i686-pc-mingw32? If one is correct, why? If both are correct, how does one decide which one to use? - I notice that if I merely use --host=mingw32, config.guess will equate mingw32 as i386-unknown-mingw32. Why? - Is there a plan to get 32 from mingw32, i.e. mingw? Of course, that won't be useful with old projects that still need the 32 to be present... :( === Now my results: - I never see configure look for i686-pc-mingw32-gcc. It merely picks up 'gcc'. Any ideas why? Do you have an accessible i686-pc-mingw32-gcc ? have a look at the configure script - it may provide some clues :}. Rob Sorry... I left that out. Yes, I do have an accessible i686-pc-mingw32-gcc, and I am looking at the configure script. It just searches for gcc. It doesn't bother to look for the prefixed tool. Jon -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
- Original Message -
From: Jon Leichter [EMAIL PROTECTED]
Sorry... I left that out. Yes, I do have an accessible
i686-pc-mingw32-gcc,
and I am looking at the configure script. It just searches for gcc. It
doesn't bother to look for the prefixed tool.
Are you sure? Here's the output of a configure script here.
Administrator@LIFELESSWKS /usr/src/squid/t
$ ../auth_rewrite/configure --host=i686-pc-linux --build=i686-pc-cygwin
checking for a BSD compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking whether to enable maintainer-specific portions of Makefiles...
no
*checking for i686-pc-linux-gcc... no**
checking for gcc... gcc
checking for C compiler default output...
If you don't see that line, then one or more tests are missing from your
configure.in
these two should enable that functionality.
AC_CANONICAL_HOST
AC_PROG_CC
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
-Original Message-
From: Robert Collins [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 10, 2002 5:45 PM
To: Jon Leichter
Cc: [EMAIL PROTECTED]
Subject: Re: Compiling apps to Mingw32 with cygwin
- Original Message -
From: Jon Leichter [EMAIL PROTECTED]
Sorry... I left that out. Yes, I do have an accessible
i686-pc-mingw32-gcc,
and I am looking at the configure script. It just searches for gcc. It
doesn't bother to look for the prefixed tool.
Are you sure? Here's the output of a configure script here.
Administrator@LIFELESSWKS /usr/src/squid/t
$ ../auth_rewrite/configure --host=i686-pc-linux --build=i686-pc-cygwin
checking for a BSD compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking whether to enable maintainer-specific portions of Makefiles...
no
*checking for i686-pc-linux-gcc... no**
checking for gcc... gcc
checking for C compiler default output...
If you don't see that line, then one or more tests are missing from your
configure.in
these two should enable that functionality.
AC_CANONICAL_HOST
AC_PROG_CC
Rob
Yes, I'm very sure. A quick investigation has yielded the following:
- In autoconf 2.13 (I don't have 2.13.1), AC_PROG_CC is implemented with
AC_CHECK_PROG.
- In autoconf 2.52, AC_PROG_CC is implemented with AC_CHECK_TOOL.
AC_CHECK_TOOL checks for tools with a ${host} prefix. AC_CHECK_PROG does
not.
In my opinion, this serves as another example that one cannot count on a
configure script being up-to-date.
Jon
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
- Original Message -
From: Jon Leichter [EMAIL PROTECTED]
AC_CHECK_TOOL checks for tools with a ${host} prefix. AC_CHECK_PROG
does
not.
In my opinion, this serves as another example that one cannot count on
a
configure script being up-to-date.
Ouchies. I agree - yet another reason for cygwin ports to be updated by
the maintainer :}.
Rov
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
On Fri, Jan 11, 2002 at 12:52:01PM +1100, Robert Collins wrote:
- Original Message -
From: Jon Leichter [EMAIL PROTECTED]
AC_CHECK_TOOL checks for tools with a ${host} prefix. AC_CHECK_PROG
does not.
In my opinion, this serves as another example that one cannot count on
a configure script being up-to-date.
Ouchies. I agree - yet another reason for cygwin ports to be updated
by the maintainer :}.
If I am reading this correctly, this is not really a cygwin issue. It's
a cross-build issue, right?
I build all of the stuff that I support on linux. For most packages, I
have to do a lot of extra stuff (like set CC, LD, AR, RANLIB on the
command line) to get things built.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
- Original Message - From: Christopher Faylor [EMAIL PROTECTED] Ouchies. I agree - yet another reason for cygwin ports to be updated by the maintainer :}. package/port ^^^ If I am reading this correctly, this is not really a cygwin issue. It's a cross-build issue, right? Not a cygwin issue at all. Only related due to the mingw/cygwin cross compile question. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
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:[EMAIL PROTECTED]]
Sent: Thursday, January 10, 2002 5:52 PM
To: Jon Leichter
Cc: [EMAIL PROTECTED]
Subject: Re: Compiling apps to Mingw32 with cygwin
- Original Message -
From: Jon Leichter [EMAIL PROTECTED]
AC_CHECK_TOOL checks for tools with a ${host} prefix. AC_CHECK_PROG
does
not.
In my opinion, this serves as another example that one cannot count on
a
configure script being up-to-date.
Ouchies. I agree - yet another reason for cygwin ports to be updated by
the maintainer :}.
Rov
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
- Original Message - From: Jon Leichter [EMAIL PROTECTED] Thus... returning to the ORIGINAL topic of this thread... I had recommended the following to the OP: $ env CC=mgcc ./configure --host=i686-pc-mingw32 My new understanding of switches gives me new perspective. 'build' and 'target' will pickup the value of 'host'. In this context, you're telling configure that the host == build == MinGW. I've said before that MinGW in Cygwin is a loose cross-compile. So, it seems to me that this configuration is ok, especially since 'host' binaries CAN successfully run in the 'build' environment. Nope. because an autoconf script for mingw32 'build' may expect cp to be 'copy', sh to be cmd.exe and further stuff that will break or misbehave on cygwin. $ env CC=mgcc ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin is acceptable. We agreed that as of today that 'build', if not specified, gets the value of 'host'. Even if this were to change, i.e. 'build' gets checked for automatically, my solution STILL works. In this case, it would be a cross compile, but it should still work. See above why it doesn't. mingw != cygwin :}. This leads one to draw the following conclusions: ... This whole thread went off on a tangent suggesting that my solution was wrong. So tell me. If my solution works more often than the proper one, how is it wrong? Well.. I came in the thread late, so I get to say, 'huh, what, waddya mean?'. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
-Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 10, 2002 6:25 PM To: Jon Leichter Cc: [EMAIL PROTECTED] Subject: Re: Compiling apps to Mingw32 with cygwin - Original Message - From: Jon Leichter [EMAIL PROTECTED] See above why it doesn't. mingw != cygwin :}. If 'build' WERE to be tested automatically, independent to 'host', it would come up with 'i686-pc-cygwin'. Thus, we'd effectively end up with the same line you specified above. So that does work, right? Or are you trying to confuse me again??? :) What doesn't kill us makes us stronger. IF build were tested correctly yes. But it's not currently tested - it defaults to host IFF host is defined. Rob Well, I guess we can put that to rest... whew! :) Jon -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
Subject: Re: Compiling apps to Mingw32 with cygwin Date: Wed, 9 Jan 2002 18:11:16 +0100 From: J. Henning Schwentner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Am Montag, 7. Januar 2002 17:49 schrieben Sie: Jon Leichter wrote: - Using CC=gcc -mno-cygwin is good for compiling, but it's bad for GNU Libtool, as I have mentioned. I use a wrapper script: CC=mgcc. What do you think of this Earnie? Your wrapper script is a good idea but has the wrong name as has been pointed out already. It needs to be named i386-pc-mingw32-gcc and a copy as mingw32-gcc so that when specifying the --host=mingw32 or --host=i386-pc-mingw32 the configure script will find it appropriately. Of course to do this you also need to do the same for the binutils binaries. Do the binutils also support the -mno-cygwin switch? I'll leave that as an exercise for you to figure out. Or can the 386-pc-mingw32-binutilname files be simple links to the cygwin versions? Yes, simply symlink will do. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
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:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] Reply-To: Jon Leichter [EMAIL PROTECTED] To: J. Henning Schwentner [EMAIL PROTECTED] CC: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: [EMAIL PROTECTED] Thanks for your quick help, this works nice! But, it is a bit difficult. I think ideally configure should detect --host=mingw32 --build=cygwin and in this case should add --mno-cygwin to CFLAGS and CPPFLAGS (and do something to fix libtool). Both of these are incorrect and both say the same thing as far as configure is concerned. You need to specify the full triplet when using `gcc -mno-cygwin' as your compiler. The method used above tells configure that your cross compiling wanting to build an executable for i386-pc-mingw32 using i686-pc-cygwin. Instead you should: CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' ./configure --host=i386-pc-mingw32 --build=i386-pc-mingw32 --target=i386-pc-mingw32 OR (if your config.guess and config.sub support it) CC='gcc -mno-cygwin' CXX='g++ -mno-cygwin' ./configure --host=mingw32 --build=mingw32 --target=mingw32 You probably currently see configure scripts check for cross compiling and end up with a value of `no' because the executable can be executed. This method, IIRC, has changed as of autoconf-2.50 which now compares the values of host and build to determine the value for cross compiling. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
Jon Leichter wrote: - Using CC=gcc -mno-cygwin is good for compiling, but it's bad for GNU Libtool, as I have mentioned. I use a wrapper script: CC=mgcc. What do you think of this Earnie? Your wrapper script is a good idea but has the wrong name as has been pointed out already. It needs to be named i386-pc-mingw32-gcc and a copy as mingw32-gcc so that when specifying the --host=mingw32 or --host=i386-pc-mingw32 the configure script will find it appropriately. Of course to do this you also need to do the same for the binutils binaries. Yes, specifying --host without the other parts of the triplet indicates a cross build to configure. You are even warned of this fact. Specify all three to avoid configure from figuring it out on it's own. You've just been lucky enough to not configure a package that cares. Try configuring binutils if you want to see what happens with just specifying host. Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
Dear Earnie, I do not get it with the --build switch. Am I not building on i686-pc-cygwin? Is it i368-pc-mingw because I use the mingw-headers? But I use the cygwin-compiler. Sorry, but I am confused a bit ... Your wrapper script is a good idea but has the wrong name as has been pointed out already. It needs to be named i386-pc-mingw32-gcc and a copy as mingw32-gcc so that when specifying the --host=mingw32 or --host=i386-pc-mingw32 the configure script will find it appropriately. Of course to do this you also need to do the same for the binutils binaries. Should'nt these scripts be included in the standard cygwin-gcc- (and binutils-) distribution? It would be very easy to include them, and compiling for the mingw32 target would also be a lot easier. -- J. Henning Schwentner Lanthan Software KG _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling apps to Mingw32 with cygwin
Thanks for your quick help, this works nice! But, it is a bit difficult. I think ideally configure should detect --host=mingw32 --build=cygwin and in this case should add --mno-cygwin to CFLAGS and CPPFLAGS (and do something to fix libtool). I am not sure if this is a bit off topic, maybe this sould be posted to the autoconf list. Regards, Henning _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of J. Henning Schwentner Sent: Sunday, January 06, 2002 5:57 AM To: [EMAIL PROTECTED] Subject: Re: Compiling apps to Mingw32 with cygwin Thanks for your quick help, this works nice! But, it is a bit difficult. I think ideally configure should detect --host=mingw32 --build=cygwin and in this case should add --mno-cygwin to CFLAGS and CPPFLAGS (and do something to fix libtool). I am not sure if this is a bit off topic, maybe this sould be posted to the autoconf list. Regards, Henning _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Compiling apps to Mingw32 with cygwin
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of J. Henning Schwentner Sent: Saturday, January 05, 2002 7:42 AM To: [EMAIL PROTECTED] 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/
