delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2005/02/01/14:09:16

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
Date: Tue, 1 Feb 2005 14:09:27 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Problems creating "-mno-cygwin" DLLs with libtool.
Message-ID: <20050201190927.GA6746@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <20050201172639 DOT GH4911 AT trixie DOT casa DOT cgf DOT cx> <NUTMEGD2p3LisRSQXJI000003f4 AT NUTMEG DOT CAM DOT ARTIMI DOT COM>
Mime-Version: 1.0
In-Reply-To: <NUTMEGD2p3LisRSQXJI000003f4@NUTMEG.CAM.ARTIMI.COM>
User-Agent: Mutt/1.4.1i

On Tue, Feb 01, 2005 at 06:15:50PM -0000, Dave Korn wrote:
>> -----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.

Unless someting has changed, -mno-cygwin doesn't pass options off to
another compiler.  It's just one compiler which changes state based on
that flag.

Regardless, as you know, there is no intelligence in the gcc front end
that says "Hey the user passed both -mno-cygwin and -lcygwin! I'll
complain." I don't think it is appropriate for that level of
intelligence to be in the compiler.  It's barely possible that someone
might know what they are doing and want that.  I don't think you are
actually advocating this, but I thought I'd elucidate anyway.

The existence of -mno-cygwin is primarily for parts of the cygwin tools
which require it.  If I had it to do over again, I would never have done
things this way.  I don't see any reason for other package maintainers
to go out of their way to accommodate this switch.  It's a kludge.

If you truly want a native windows binary, then it seems to me that you'd
be better served using the tools from the project which is dedicated to
its support.

YMMV.  Maybe Chuck will disagree and work diligently to make sure that
libtool supports this.

If so, nevermind.

cgf

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019