Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <3C7309A1.1030207@ece.gatech.edu>
Date: Tue, 19 Feb 2002 21:27:45 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Edouard Gomez <ed DOT gomez AT wanadoo DOT fr>
CC: cygwin AT cygwin DOT com
Subject: Re: BUG with 1.3.9 : -mno-cygwin target still depends on cygwin1.dll
References: <3c72e52d3d0da4b8 AT mel-rta3 DOT wanadoo DOT fr> <20020220003507 DOT GE22591 AT redhat DOT com> <20020220020824 DOT GA4764 AT wanadoo DOT fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Edouard,

You're using the cygwin tools to do what is basically a cross-compile. 
However, libtool in particular doesn't grok that "gcc -mno-cygwin" == 
"cygwin hosted mingw compiler".  So, there are problems.

Search the archives -- this was recently discussed on the main list. 
There was a big "argument" about whether "gcc -mno-cygwin" was a "mode" 
of a cygwin-hosted, cygwin-target compiler, or whether it was an actual 
cross-compiler "in disguise".  It sounds like a trivial distinction, I 
know, but it makes a BIG difference in how the autotools behave.

There were suggestions of using scripts similar to the following
---begin mingw-pc-gcc ----
#!/bin/sh
gcc -mno-cygwin $*
---end mingw-pc-gcc ------

and similar(for all the binutils tools).  Then you'd just configure as:

./configure --target=i686-pc-mingw

and (hopefully) the autotools would figure it all out.

There was also a suggestion that a "real" cygwin-hosted-mingw-target 
gcc/binutils be supplied as a cygwin package, that could install 
alongside the "normal" cygwin gcc.  I dunno what the status of that is.

Then, there was the simple suggestion to just 'export CC="gcc 
-mno-cygwin"' -- but libtool doesn't accept that.  automake and autoconf 
kinda mostly work okay in this configuration -- but libtool, definitely not.

But the point is, using 'gcc -mno-cygwin' really only works if you're 
doing the "work" by hand: hand-written makefiles, custom build commands, 
etc.

Given the above problems, coupled with the *total* lack of 
autotoolability (?) in mingw, Earnie Boyd created a fork of cygwin 
called "msys".  The goal of msys is to provide a cygwin-like environment 
(bash shells, scripting, autotools "work", etc) -- but everything in the 
environment is targetted toward building native, non-cygwin applications 
using the mingw compiler suite.  Take a look at the mingw website.

Or lobby for "someone" to provide a mingw-target cygwin-host 
cross-compiler suite as an official cygwin package.

--Chuck

Edouard Gomez wrote:

> Christopher Faylor (cgf AT redhat DOT com) wrote:
> 
>>Sorry, but I beg to differ.  1) It's "cygwin" not "cygwin32".  2) You're not
>>working on a cygwin port if you are linking with -mno-cygwin.
>>
>>
> 
> 1 - Sorry for this mistake
> 2 - I'm working on a cygwin port because i use the cygwin environment
>     (shell + autoconf + automake ...) but the resulting dlls don't need
>     cygwin unix elulation stuff. And as the doc says, if you don't need
>     unix emulation, use -mno-cygwin to get faster programs/libs.
>  
> 
>>Assuming that you get this working with -mno-cygwin, you will have produced
>>a executable which will be a straight windows program.  It won't understand
>>cygwin paths, signals, symbolic links, etc.
>>
>>
> 
> I don't need this stuff
> 
> 
>>Sounds like you should move over to www.mingw.org, then.
>>
>>
> 
> It's truely a cygwin problem, i use the cygwin gcc compiler, the cygwin tools
> the cygwin whateveryoulike but it doesn't do what it is expected to do.
> ie a cygwin1.dll independant lib.
> 
> I was making a bug report so please don't flame me without good arguments.
> 
> Regards
> 
> 



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