Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: Problems creating "-mno-cygwin" DLLs with libtool.
Date: Tue, 1 Feb 2005 18:15:50 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20050201172639.GH4911@trixie.casa.cgf.cx>
Message-ID: <NUTMEGD2p3LisRSQXJI000003f4@NUTMEG.CAM.ARTIMI.COM>
X-OriginalArrivalTime: 01 Feb 2005 18:15:50.0282 (UTC) FILETIME=[0F2996A0:01C5088A]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Christopher Faylor
> Sent: 01 February 2005 17:27

> Has it been established that the cygwin version of libtool is *supposed*
> to handle mingw?  I'd be rather surprised if that was a goal.

  Nope, I just assumed that it could be made to do so, and possibly quite
easily.  After all, the cygwin version of gcc is supposed to handle the
-mno-cygwin switch.  Yes, I understand it's not responsible for implementing it,
that it's just a flag that tells it to hand off to another compiler, but at the
same time it (IIUIC) shouldn't pass "-lcygwin" to the mingw compiler and it
would be a bug in the cygwin gcc (to be precise in the specs file) if it did.
So I figured by the same reasoning as the cygwin-gcc compiler should still
process command-line options intelligently even when it's only passing them on
to mingw-cc1 and getting out of the way, there's no reason why cygwin-libtool
can't try to DTRT too.  It's perhaps mildly inconsistent/anomalous if gcc is the
only part of the toolchain that's cygming-special and the rest is completely
ming-agnostic.

> OTOH, I never have understood why tools insist on including such things as
> "-lcygwin" or "-lc" on a linker command line.

  NIH syndrome I would have thought - the old "well, if we control it *all*,
it'll be easier to get right" fallacy.

[Offtopic sidenote on software engineering 'best practice']  Of course, it's
_actually_ a whole lot easier to get things right when you let the tools (that
understand what flags they need) set those same flags.  Don't second-guess your
compiler!  Don't duplicate knowledge in more than one place!  Delegate authority
and *trust* your delegates to get it right!

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/