Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
From: "Jon Leichter" <jon AT symas DOT com>
To: <cygwin AT cygwin DOT com>
Subject: Potential problems with Cygwin GCC and -mno-cygwin switch
Date: Wed, 26 Dec 2001 20:33:56 -0800
Message-ID: <DLEBJKNCNLJEDKMKICHGCEMMCAAA.jon@symas.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal

Hello all.

It's been a long time since I was active on this list. I have not used
Cygwin for over a year, until recently. I see that Cygwin has been updated
quite a bit since I last used it. It's very nice to see these new features.

I have a couple of issues to discuss about Cygwin GCC and it's MinGW
support.

Before I get started, I'd like to make an observation. The MinGW web site
(http://www.mingw.org/mingwfaq.shtml#faq-usingwithcygwin) suggests that:

	1) MinGW support in Cygwin GCC is flaky and buggy
	2) MinGW support in Cygwin GCC will possibly be deprecated
	3) a better solution for MinGW binaries from a Cygwin environment
	   is to install MinGW GCC over Cygwin

From what I've seen, it looks like MinGW support in Cygwin GCC is up-to-date
and better than ever before. So, I have no idea what the MinGW web site is
referring to. Does anyone from Cygwin agree that MinGW support will be
deprecated?

I, personally, find it much better to build MinGW binaries with Cygwin GCC.
In my work, I often build projects with shell scripts. Using the Cygwin bash
shell is the easiest (if not, the only) way to interpret these shell
scripts. Many times, shell scripts create symbolic links and specify them to
compiler tools as parameters. Only a Cygwin binary can interpret these
symbolic links. If a symbolic link were specified as a parameter to a MinGW
compiler tool, it would fail. Thus, I fail to see how MinGW GCC over Cygwin
is a better solution than MinGW support provided by Cygwin GCC.

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.

========

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.

=========

3) There's a problem with Cygwin-specific libraries residing in /usr/lib.
Generic GCC has /usr/lib and /lib hard-coded as default library search
directories. If a library specified on the link line (of a gcc -mno-cygwin
invocation) does not exist in /usr/lib/mingw but does exist in /usr/lib,
that library will get linked into the binary instead of an error being
generated. An example: OpenLDAP's configure script looks for libncurses
support in the build environment. If I'm building MinGW OpenLDAP, it finds
libncurses in /usr/lib. The libncurses import library resolves to
cygncurses6.dll. If I'm building MinGW OpenLDAP, I don't want any Cygwin
binaries linked into it.

What I've done to get around this problem is relocate all Cygwin libraries
and object files from /usr/lib to /usr/lib/cygwin. Here's how I did it:

	$ cd /usr/lib
	$ mkdir cygwin
	$ mv lib* cygwin
	$ mv *.dll *.o cygwin

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.

I wonder if anyone else thinks it would be a good idea to relocate Cygwin
libraries as a standard part of the distribution. Note that I am talking
about relocating link-time libraries and object files, not the actual DLLs
in /usr/bin. Also, I wonder if the headers should be relocated. There is not
a problem with header processing at all. I'm just mentioning it for
symmetry. (I have not relocated my Cygwin headers).

=========

I know the motto of OpenSource. If there's something you don't like, fix it
and submit the patch. Unfortunately, I won't be able to do this. I recognize
that no changes may come about. However, I am mentioning these topics to see
what other people think, and I suspect that some of these isses might be
easy fixes that somebody else (who participates in Cygwin development) might
be able to quickly handle.

Jon


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