Compiling euchre 0.7 n cygwin

[mwoehlke]

mwoehlke wrote:
> TITTTLing

Naturally, I meant that I *meant* to TITTTL :-) Sorry 'bout that.

> Dave Korn wrote:
>> 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?
> 
> Well, sure, and the fact that the linker *gives* you that second chance. 
> Most linkers will fail if there are unresolved symbols, so in that 
> sense, Linux ld is more forgiving. The order issue is that if you 
> specify the lib before the object, it doesn't know what to import from 
> the lib (but I think it stills makes a note that that lib should be 
> loaded, no?).

-- 
Matthew
"We're all mad here. I'm mad. You're mad... You must be, or you wouldn't 
have come here." -- The Cheshire Cat