X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: Compiling euchre 0.7 n cygwin
Date: Thu, 20 Jul 2006 19:17:25 +0100
Message-ID: <033901c6ac28$c08e5320$a501a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <e9of68$d1p$1@sea.gmane.org>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
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

On 20 July 2006 18:40, mwoehlke wrote:

> Laurent Duperval wrote:
>> Buster wrote:
>>> This is not a Cygwin-specific problem. In
>>> euchre-0.7/src/gui/Makefile.am, @GTK_LIBS@ should come at the end of
>>> the list of libraries to link, instead of at the beginning. Further
>>> questions (for example, about why 'make install' fails while trying to
>>> invoke automake -- sorry, it's beyond me) should be directed to the
>>> package maintainer.
>> 
>> Excellent! Changing the order of the libs fixed the problem.
>> 
>> I ended up having to change it directly in the Makefile instead of
>> Makefile.am (I probably could've done it in Makefile.in also).
>> 
>> The reason I thought it was a Cygwin issue is that the same code
>> compiles fine on Linux (except for a minor ifstream issue).
> 
> Right... Linux is forgiving about link order. Most platforms aren't.

  Isn't it actually more to do with the fact that Linux tends to use shared
libs, and so if the link order is wrong you get an executable with unresolved
symbols in it, but then those unresolved symbols get resolved anyway at
runtime when the library is loaded by ld.so, whereas here on cygwin we tend to
use static link libs, even when we're linking against a .dll, and so don't get
the equivalent 'second chance' to resolve?


    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/