This is the mail archive of the
mailing list for the Cygwin project.
Re: BUG with 1.3.9 : -mno-cygwin target still depends on cygwin1.dll
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 ----
gcc -mno-cygwin $*
---end mingw-pc-gcc ------
and similar(for all the binutils tools). Then you'd just configure as:
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,
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.
Edouard Gomez wrote:
> Christopher Faylor (firstname.lastname@example.org) 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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html