From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30953 invoked by alias); 28 Aug 2003 13:38:52 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 30933 invoked from network); 28 Aug 2003 13:38:51 -0000 Received: from unknown (HELO garm.central.cmich.local) (141.209.15.48) by sources.redhat.com with SMTP; 28 Aug 2003 13:38:51 -0000 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Aug 2003 09:38:50 -0400 Received: from localhost (unknown [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id A17BA70016; Thu, 28 Aug 2003 09:38:47 -0400 (EDT) Date: Fri, 29 Aug 2003 00:44:00 -0000 From: Eric McDonald To: Juergen Ruehle Cc: xconq7@sources.redhat.com Subject: Re: New Xconq Windows Executable In-Reply-To: <16205.61436.450000.631353@lapjr.intranet.kiel.bmiag.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 28 Aug 2003 13:38:50.0790 (UTC) FILETIME=[B7211C60:01C36D69] X-SW-Source: 2003/txt/msg00386.txt.bz2 On Thu, 28 Aug 2003, Juergen Ruehle wrote: > Eric McDonald writes: > > Yes, it does depend on the Cygwin XFree86 X libraries. We would > > then need to have people install the Cygwin XFree86 stuff (which, > > IMO, is much more stable than 2 years ago). And they would > > essentially be playing Unix Xconq in an X display on their Windows > > machine. > > Actually no: the cygwin tk does not depend on X, but it doesn't > contain the right headers either. You have to download the source to > the tcl/tk package, extract the headers, and configure using OK, "depend" was too strong of a word. During my earliest build attempt, I was picking up the wrong Tcl/Tk (I forgot that I had the Cygwin version of it installed, and its headers were in /usr/include which was earlier in the search path than the AS headers), and when compiling tkwin32.c, I was getting conflicts with what I _assumed_ were the actual X headers that Tcl/Tk "depended" on. I'll eat my words for now, until I can verify what X headers were actually being used (next time I boot into Windows). Sorry for possibly dispensing misinformation based on an assumption.... > --x-includes=<> > (Probably the same you are doing to compile with the AS package). Yes. > Otherwise configure will find the standard X11 headers which are > incompatible and the resulting application will crash on startup. Actually, you probably won't make it past linking, because of the overridden definitions at the bottom of tkwin32.c. > Also it seems there is still some tweaking of at least win/Makefile.in > neccessary. it would be nice if somebody could commit something along > the lines of (one still has to muck with TCLTKLIB, but I see no way to > autodetect this): I had some similar tweaks in mind, based on my experience with that mess. I will look at your patch more closely tonight (US Mountain time), unless someone has already committed it by then. Thanks. Best regards, Eric