From: "Gary R. Van Sickle" <g.r.vansickle@worldnet.att.net>
To: <cygwin@cygwin.com>
Subject: RE: A build problem of C++ code on Cygwin
Date: Tue, 22 Aug 2006 19:54:47 -0500
Message-ID: <003701c6c64e$bb6ba2e0$020aa8c0@DFW5RB41>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <44EB9366.F1F9A629@dessent.net>
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

> From: Brian Dessent
> Sent: Tuesday, August 22, 2006 6:30 PM
> Subject: Re: A build problem of C++ code on Cygwin
> 
> Brian Dessent wrote:
> 
> > I've seen this a million times.  It's a makefile that doesn't know 
> > about $EXEEXT and assumes that executables have no 
> extension.  Because 
> > of this one of the stock built-in make rules gets invoked 
> instead of 
> > the proper link command.  Look in the Makefile for the rule that 
> > generates the final binary and I'm willing to bet that it has no 
> > $EXEEXT.  This works fine on linux because there is no 
> extension for executables there.
> 
> Indeed.  The attached patch (and then re-running automake at the
> top-level) causes the build to work correctly -- or at least 
> get past the problem you reported, I don't feel like waiting 
> for the full build.
> 
> You should report this upstream.  The change should be safe 
> for any platform.
> 
> Brian

Another very similar one to watch out for are makefiles that actually do
support $EXEEXT, but for whatever reason $EXEEXT gets set to nothing.  I
think it's mainly hand-rolled makefiles these days, but IIRC if somebody's
using crusty enough autotools they'll get configures that do this to you.

-- 
Gary R. Van Sickle
 

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