Re: BUG with 1.3.9 : -mno-cygwin target still depends on cygwin1.dll

[Charles Wilson <cwilson at ece dot gatech dot edu>]

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@redhat.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/