Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Message-ID: <01C18315.AF4D11A0.jorgens@coho.net>
From: Steve Jorgensen <jorgens AT coho DOT net>
Reply-To: "jorgens AT coho DOT net" <jorgens AT coho DOT net>
To: "'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
Subject: RE: gcc -mno-cygwin creates cygwin executables!
Date: Wed, 12 Dec 2001 14:02:12 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


On Wednesday, December 12, 2001 1:10 PM, Christopher Faylor 
[SMTP:cgf AT redhat DOT com] wrote:
> On Wed, Dec 12, 2001 at 09:55:25PM +0100, Teun Burgers wrote:
> >egor duda wrote:
> >
> >> you're fixing specific symptoms instead of the problem itself. this
> >> had been discussed already and the general consensus (at least as i
> >> understand it) is the following: -mno-cygwin is a _hack_. it's
> >> supposed to be used only when absolutely necessary and when you
> >> absolutely know what you're doing.
> >
> >-mno-cygwin certainly is very good hack. I hoped I was contributing
> >to making it an even better hack.
>
> If you want to contribute to it, then contribute to what I described in
> my original message -- fix 'ld' so that it doesn't have to search 
/usr/lib
> by default.
>
> Anything else you've proposed has just been a workaround.  I am really
> not going to subvert the current cygwin DLL layout to accomodate
> -mno-cygwin.  Or, let me amend this in the usual way.  If you think that
> this is a good idea, send a patch which accomplishes your idea.
> Otherwise, I guarantee you that this idea will go nowhere.
>
> Speaking of going nowhere, -mno-cygwin is not going anywhere either.  It
> will always be around.  However, I like to dream that the only thing
> this option will do is to invoke a i686-pc-mingw32-gcc compiler.
>
> Otherwise, I fear that we'll always be suffering from cross-pollution 
from
> the cygwin libraries.
>
> Although, sadly, if cygwin and mingw exist on the same machine, we'll
> *always* be getting "bug reports" from people who complain that
> constructions like:
>
> i686-pc-mingw-gcc -o foo.exe -Ic:/cygwin/usr/include/signal.h foo.c
>
> doesn't work right!!!!
>
> >>*** if you want to build executables for mingw platform you should use
> >>mingw toolchain, either native or cross.  ***
> >
> >setup.exe is a huge success of cause and makes things very easy to
> >install.  I have never looked at the mingw toolchain, but I bet the
> >cygwin stuff is a lot easier to install.
> >
> >And with a bit of attention paid to the configure script a package can
> >build out-of-the box with gcc -mno-cygwin.  This is much better than
> >the often ill maintained mingw specific makefiles, if they are there at
> >all.
>
> That may be, but -mno-cygwin is a decidedly low-priority goal for the 
Cygwin
> project.  The primary reason is that we don't have anyone other than me
> "interested" in supporting it.

Personally, I think the hope of being able to use configure for compiling a 
native w32 executable is a very important capability to have whether it is 
through Cygwin or not.  Is that likely to be possible any other way than 
through Cygwin?  If there's a better answer on the horizon, I'd like to 
know about it.

Eventually, I'm hoping to be able to compile GNOME apps for native Windows, 
and I see anything that takes autotools out of the loop as 
counterproductive.  It would mean that I would always have to play catch-up 
to make newer versions work.

--
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/