Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/