RE: cygqwin with mingw32 question
Jonathan, I have to admit that I don't quite understand your original question either. However, it seems like you're interested in understanding some of the internals of Cygwin's gcc and the -mno-cygwin switch. First of all, a quick response: when you specify -mno-cygwin to the compiler, __CYGWIN__ is NOT defined. Rather, __MINGW32__ is defined. In the past, I made contributions to OpenLDAP so that it would build as MinGW binaries with Cygwin gcc. As part of this contribution, I wrote a detailed document on Cygwin, MinGW, and the internals of how they relate to each other. You can read this document on OpenLDAP's web site: http://www.openldap.org/faq/data/cache/301.html I don't vouch for its accurracy. I last updated it in December, but you know how quickly software changes. Also, the content is based purely on my experience as a user and not a developer of Cygwin. So there may be things I'm wrong about. Nevertheless, it's fairly comprehensive. I hope this helps... Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Wilson Sent: Friday, March 29, 2002 3:57 AM To: [EMAIL PROTECTED] Subject: Re: cygqwin with mingw32 question I did see that but what I dont understand is if __CYGWIN__ is defined when -mno-cygwin is selected. I also need to know if cygwin GCC defines some specific flag that I can test for that identifies it as GCC. -- 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: DLL a question
Here's a method that I have used successfully: - Build your Cygwin DLL. Whether you build the DLL with dlltool, dllwrap, or libtool, a .def file should be produced in the process. - Use MSVC's command line tool lib with the /def option and your .def file to generate an MSVC-style .lib import library. - Link your MSVC project with the .lib import library. Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of McLeod, John Sent: Thursday, February 07, 2002 7:37 AM To: [EMAIL PROTECTED] Cc: 'Nguyen Minh Le' Subject: RE: DLL a question The DLL Stuff download dllhelpers-0.2.9.tar.bz2 at http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/dll-stuff/ has examples of making DLL's with C, C++, and Fortran under Cygwin. I don't have a simple example of using these with Microsoft Visual C/C++, but if by luck you have access to RSI's (proprietary) IDL 5.5 product ( http://www.rsinc.com/ ) their CALL_EXTERNAL example contains source code to make a VC DLL, and this example can be compiled on CYGWIN (following the examples in DLL STUFF) and the resulting DLL used by the IDL CALL_EXTERNAL function. Hope this helps, John -Original Message- From: Nguyen Minh Le [mailto:[EMAIL PROTECTED]] Sent: Thursday, 7 February 2002 5:04 a.m. To: [EMAIL PROTECTED] Subject: DLL a question Hi All, Could you tell me a example in writing dll in Cygwin and use it in VC (windows). Thank you, Nguyen -- 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/ -- 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
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: 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
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: 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: 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
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: 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
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
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/
RE: CHMOD propblem !!!
Seeing how G:\CYGWIN\BIN is further in your path than some other significant directories, I'm wondering if you're executing the correct 'chmod' binary. From a bash shell, show us the output of the following: $ type chmod === Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of JOSE (GRI) Sent: Wednesday, January 02, 2002 12:54 AM To: [EMAIL PROTECTED] Subject: Re: CHMOD propblem !!! I'm out of ideas :( Have you tried chmod-ing from the bash shell ? Can you post the output of cygcheck -r -s -v ? Cygnus Win95/NT Configuration Diagnostics Current System Time: Wed Jan 02 08:50:20 2002 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 2 Path: D:\PERL\BIN C:\WINNT\SYSTEM32 C:\WINNT C:\WINNT\SYSTEM32\WBEM S:\MC S:\RCS\BINNT G:\CYGWIN\BIN I:\PHP I:\PHP\extensions S:\Jdk1.3.1\JRE\BIN\classic S:\Jdk1.3.1\bin S:\Jdk1.3.1\jre\bin S:\Jdk1.3.1\lib D:\Microsoft Visual Studio\Common\Tools\WinNT D:\Microsoft Visual Studio\Common\MSDev98\Bin D:\Microsoft Visual Studio\Common\Tools D:\Microsoft Visual Studio\VC98\bin S:\WATCOM\BINNT S:\WATCOM\BINW SysDir: C:\WINNT\System32 WinDir: C:\WINNT CYGWIN = `ntsec' Path = `D:\PERL\BIN;C:\WINNT\SYSTEM32;C:\WINNT;C:\WINNT\SYSTEM32\WBEM;S:\ MC;S:\RCS\BINNT;G:\CYGWIN\BIN;I:\PHP;I:\PHP\extensions;S:\Jdk1.3.1 \JRE\BIN\classic;S:\Jdk1.3.1\bin;S:\Jdk1.3.1\jre\bin;S:\Jdk1.3.1\l ib;D:\Microsoft Visual Studio\Common\Tools\WinNT;D:\Microsoft Visual Studio\Common\MSDev98\Bin;D:\Microsoft Visual Studio\Common\Tools;D:\Microsoft Visual Studio\VC98\bin;S:\WATCOM\BINNT;S:\WATCOM\BINW' USER = `JOSE' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\jose\Datos de programa' CommonProgramFiles = `C:\Archivos de programa\Archivos comunes' COMPUTERNAME = `PC3' ComSpec = `C:\WINNT\system32\cmd.exe' EDPATH = `S:\WATCOM\EDDAT' HOMEDRIVE = `C:' HOMEPATH = `\' INCLUDE = `D:\Microsoft Visual Studio\VC98\atl\include;D:\Microsoft Visual Studio\VC98\mfc\include;D:\Microsoft Visual Studio\VC98\include;S:\WATCOM\H;S:\WATCOM\H\NT' lib = `D:\Microsoft Visual Studio\VC98\mfc\lib;D:\Microsoft Visual Studio\VC98\lib' LOGONSERVER = `\\PC3' MCASE = `JOSE' MSDevDir = `D:\Microsoft Visual Studio\Common\MSDev98' NUMBER_OF_PROCESSORS = `1' OS = `Windows_NT' Os2LibPath = `C:\WINNT\system32\os2\dll;' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 5 Model 8 Stepping 12, AuthenticAMD' PROCESSOR_LEVEL = `5' PROCESSOR_REVISION = `080c' ProgramFiles = `D:\' PROMPT = `$P$G' SystemDrive = `C:' SystemRoot = `C:\WINNT' TEMP = `C:\DOCUME~1\jose\CONFIG~1\Temp' TMP = `C:\DOCUME~1\jose\CONFIG~1\Temp' TZ = `CET' USERDOMAIN = `PC3' USERNAME = `jose' USERPROFILE = `C:\Documents and Settings\jose' WATCOM = `S:\WATCOM' windir = `C:\WINNT' WWINHELP = `S:\WATCOM\BINW' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0020 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/bin (default) = `G:\cygwin\bin' flags = 0x HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/client (default) = `S:\client' flags = 0x HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/comun (default) = `S:\comun' flags = 0x HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/jdk1.3.1 (default) = `s:\jdk1.3.1' flags = 0x HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/tmp (default) = `g:\cygwin\tmp' flags = 0x HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `G:/cygwin/lib' flags = 0x HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\08 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\09
RE: Potential problems with Cygwin GCC and -mno-cygwin switch
Ok... you got me... One problem with cyberspace communication is how two (or more) people can be talking about the same topic but are on different pages (metaphorically, of course)... :) What I was talking about is packages that you download and build yourself, e.g. GNU regex, GNU libtool, GDBM, OpenLDAP: all of these packages configure with a default prefix of /usr/local. I was not talking about pre-packaged Cygwin binaries. And I still claim that even after you install Cygwin packages, they will operate if you relocate the libraries in /usr/lib. This is because the Cygwin binaries depend on DLLs accessible via the PATH, which are NOT relocated from /usr/bin. Jon -Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 27, 2001 6:23 PM To: Jon Leichter Cc: [EMAIL PROTECTED] Subject: Re: Potential problems with Cygwin GCC and -mno-cygwin switch - Original Message - From: Jon Leichter [EMAIL PROTECTED] Most libraries included with packages install in /usr/local/lib (opposed to /usr/lib). As for libraries that it may depend upon, as long as my GCC specs file knows where to find libraries, I don't see a problem. Please check your facts before making assertions. === $ ls -lR /usr/local/lib/ /usr/local/lib/: total 0 drwxrwxrwx2 Administ None0 Dec 27 22:00 pkgconfig /usr/local/lib/pkgconfig: total 0 === I have nearly every package provided by cygwin installed, and as you can see, the libraries are not installed in /usr/local/lib. 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: Potential problems with Cygwin GCC and -mno-cygwin switch
-Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 27, 2001 6:35 PM To: Jon Leichter Cc: [EMAIL PROTECTED] Subject: Re: Potential problems with Cygwin GCC and -mno-cygwin switch However , once gcc's specs are changedm linking with the libraries they provide will fail - which is what I was talking about. Hmm... I'm not sure why this would be the case. I have relocated my libraries, and I have updated my specs file. Things work just fine for me (or it seems). I wonder if you could elaborate your assertion with an example. (I don't want to upset Chris Faylor - is this something we should discuss off the mailing list?) (Until every package gets repackaged, at a significant time cost to the package maintainers). And as this would be (at best) an interim fix until gcc is corrected, I for one do not support implementing this - the time cost would get gcc fixed many times over. Rob Based on the conversation we've been having, I no longer think this is a general good idea either. I stated this is a previous email. I agree that the right solution is to correct gcc. The relocation that I have done merely serves as an interim solution for me. 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: Potential problems with Cygwin GCC and -mno-cygwin switch
- Original Message - From: Jon Leichter [EMAIL PROTECTED] However , once gcc's specs are changedm linking with the libraries they provide will fail - which is what I was talking about. Hmm... I'm not sure why this would be the case. I have relocated my libraries, and I have updated my specs file. Things work just fine for me (or it seems). I wonder if you could elaborate your assertion with an example. (I don't want to upset Chris Faylor - is this something we should discuss off the mailing list?) It's an onlist topic. Because the two things have to happen concurrently. Cygwin has over a 100 packages, of which maybe 40 provide libraries that would need to be relocated. The mechanism for relocation is quite simple: every package maintainer repackages their package with the libraries in the new location. I think I understand what you're saying now. The wording in your previous email threw me off. I'm not sure the two things have to happen concurrently. If the GCC specs file were to change first, then GCC would start looking in /usr/lib/cygwin, and it would continue to look in (the hard-coded path) /usr/lib, where old package libraries would still reside. Also, I'm not sure that all packages need to be relocated. Just the ones that place files in /usr/lib. There is no problem with a package that places files in a subdirectory of /usr/lib. At this point, this conversation is purely hypothetical... :) I really don't think 100 packages should should be re-packaged... 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/
Potential problems with Cygwin GCC and -mno-cygwin switch
Hello all.
It's been a long time since I was active on this list. I have not used
Cygwin for over a year, until recently. I see that Cygwin has been updated
quite a bit since I last used it. It's very nice to see these new features.
I have a couple of issues to discuss about Cygwin GCC and it's MinGW
support.
Before I get started, I'd like to make an observation. The MinGW web site
(http://www.mingw.org/mingwfaq.shtml#faq-usingwithcygwin) suggests that:
1) MinGW support in Cygwin GCC is flaky and buggy
2) MinGW support in Cygwin GCC will possibly be deprecated
3) a better solution for MinGW binaries from a Cygwin environment
is to install MinGW GCC over Cygwin
From what I've seen, it looks like MinGW support in Cygwin GCC is up-to-date
and better than ever before. So, I have no idea what the MinGW web site is
referring to. Does anyone from Cygwin agree that MinGW support will be
deprecated?
I, personally, find it much better to build MinGW binaries with Cygwin GCC.
In my work, I often build projects with shell scripts. Using the Cygwin bash
shell is the easiest (if not, the only) way to interpret these shell
scripts. Many times, shell scripts create symbolic links and specify them to
compiler tools as parameters. Only a Cygwin binary can interpret these
symbolic links. If a symbolic link were specified as a parameter to a MinGW
compiler tool, it would fail. Thus, I fail to see how MinGW GCC over Cygwin
is a better solution than MinGW support provided by Cygwin GCC.
While I do think Cygwin GCC currently does a great job of supporting MinGW,
I do have a few issues with it:
1) The --print-search-dirs switch outputs the same information whether or
not the -mno-cygwin switch is specified. This is a problem particularly for
GNU libtool. When the command gcc -mno-cygwin --print-search-dirs is
executed, it ought to output the MinGW-specific directories and leave the
Cygwin-specific directories out. GNU libtool also expects a semi-colon as
the path separator.
2) In the specs file, /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs, the
following switch is declared in the *link section:
--dll-search-prefix=cyg
It seems to me that this switch should not be specified when GCC is in MinGW
mode. A fix would be to alter to the declaration:
%{!mno-cygwin:--dll-search-prefix=cyg}
Indeed, I have done this in my own specs file.
=
3) There's a problem with Cygwin-specific libraries residing in /usr/lib.
Generic GCC has /usr/lib and /lib hard-coded as default library search
directories. If a library specified on the link line (of a gcc -mno-cygwin
invocation) does not exist in /usr/lib/mingw but does exist in /usr/lib,
that library will get linked into the binary instead of an error being
generated. An example: OpenLDAP's configure script looks for libncurses
support in the build environment. If I'm building MinGW OpenLDAP, it finds
libncurses in /usr/lib. The libncurses import library resolves to
cygncurses6.dll. If I'm building MinGW OpenLDAP, I don't want any Cygwin
binaries linked into it.
What I've done to get around this problem is relocate all Cygwin libraries
and object files from /usr/lib to /usr/lib/cygwin. Here's how I did it:
$ cd /usr/lib
$ mkdir cygwin
$ mv lib* cygwin
$ mv *.dll *.o cygwin
I, of course, updated the specs file to accomodate this. My environment now
works flawlessly. When OpenLDAP looks for libncurses, it doesn't find it, as
it shouldn't.
I wonder if anyone else thinks it would be a good idea to relocate Cygwin
libraries as a standard part of the distribution. Note that I am talking
about relocating link-time libraries and object files, not the actual DLLs
in /usr/bin. Also, I wonder if the headers should be relocated. There is not
a problem with header processing at all. I'm just mentioning it for
symmetry. (I have not relocated my Cygwin headers).
=
I know the motto of OpenSource. If there's something you don't like, fix it
and submit the patch. Unfortunately, I won't be able to do this. I recognize
that no changes may come about. However, I am mentioning these topics to see
what other people think, and I suspect that some of these isses might be
easy fixes that somebody else (who participates in Cygwin development) might
be able to quickly handle.
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/
