Hi, On 2014-05-15 04:15+1000, Andrew Schulman wrote: > >> >> I can't understand why the ./conftest.exe differ. Trying to emulate by >> hand, I cannot reproduce it. But it is now very late here, and I can't >> debug anymore. >> >> I'm hoping that I've provided enough of a lead for someone of authority >> to decide where things are right, and where things are wrong. > > Yes, I think so! > > Thanks a lot, Shaddy. That takes us a long way to a solution. I'll look > at it from there as soon as I can. No problem. I am always happy when I can contribute to my favourite Open Source project and community. With regards to the conftest difference on 32-bit vs. 64-bit, I believe I understand it now. It seems the code configure generates for that little test fails to #include definitions for tgoto() (amongst others). In trying to emulate it, I had actually put them in my code. My method wasn't exact. If I understand correctly (and a subsequent gdb run seems to confirm it; Value returned is $1 = 0x600096230 "1" becomes a pointer to 0x96230) the difference comes about because without the prototype, gcc pins an int as the return type of tgoto(). But being a pointer, char *, on 64-bit the size mismatch (8 byte pointers, vs 4 byte int) means that the pointer passed into strcmp() (as return from tgoto()) has 4 random bytes copied in, and points to a random location. Does that sound plausible? I am not 100% sure, because considering this I thought that a 64-bit Linux should be afflicted in the same way. However despite gcc complaining as well over missing prototypes, strcmp() is being passed the correct (char *) pointer from tgoto(). Is this down to the difference in gcc (4.8 on cygwin, 4.7 on debian)? Or just the difference in architecture? In any case, I've tested the patch below, and it solves the immediate problem with screen. It probably needs to go upstream too... I'd put my hand up, but I'm unsure where upstream is exactly. -- Regards, Shaddy