Re: Potential problems with Cygwin GCC and -mno-cygwin switch

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "Jon Leichter" <jon@symas.com>
> 1) MinGW support in Cygwin GCC is flaky and buggy

That pages suggests that is _has been_ f & b - and it has. It's better
now than it ever has been, and still has ... quirks.

> 2) MinGW support in Cygwin GCC will possibly be deprecated

This won't happen unless a realistic way of building Cygwin is found!
(Cygwin cannot link to itself).

> 3) a better solution for MinGW binaries from a Cygwin environment
>    is to install MinGW GCC over Cygwin

No way! I've read what they sugegst and it will cripple any cygwin user
from being able to build cygwin linked exe's. A cygwin hosted, mingw
targeted cross compiler however, would be a great tool and would
co-exist without any difficulty.

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

I've not enough gcc innards to suggest a solution here. I suggest that
you do the following:
1) Ask just this question on a gcc specific list (how do a change the
output of print-search-dirs via the .specs, and if I can't do that
today, can anyone give me a pointer as to where I should look in the
code to add that capability). [It doesn't matter if gcc would accept
such a patch or not, cygwin often has things that the upstream don't
want in our releases, for various good reasons].
2) When you've got it working, submit it here, and the cygwin gcc
maintainer will likely pick it up and put it into the cygwin gcc release
(after testing of course)

You can hope that the cygwin gcc maintainer has the time to do 1)
himself, but I don't expect that to happen for a year or so :}.

> ========
>
> 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.

Here you may get luckly and have this (trivial change) picked up by the
maintainer. However the standard way for getting patches submitted is to
provide the output of diff -up against the original source, along with a
changelog.

> =========
>
> 3) There's a problem with Cygwin-specific libraries residing in
/usr/lib.
...
> 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.

This seems like an interesting approach. I wonder if anything would get
broken by it (other than ALL the existing packages that provide
libraries :}).

> I wonder if anyone else thinks it would be a good idea to relocate
Cygwin

I think this may be easier than fixing gcc, but I'm sure that fixing gcc
is a better long term approach. However as I don't have the time nor
inclination to fix gcc myself, my opinion is just that.

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