From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5630 invoked by alias); 15 Jul 2002 18:49:41 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5618 invoked from network); 15 Jul 2002 18:49:41 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 15 Jul 2002 18:49:41 -0000 Received: from makita.cygnus.com (makita.sfbay.redhat.com [192.168.30.83]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA11727 for ; Mon, 15 Jul 2002 11:49:40 -0700 (PDT) Received: from localhost (keiths@localhost) by makita.cygnus.com (8.8.8+Sun/8.6.4) with ESMTP id LAA16533 for ; Mon, 15 Jul 2002 11:49:40 -0700 (PDT) X-Authentication-Warning: makita.cygnus.com: keiths owned process doing -bs Date: Mon, 15 Jul 2002 12:00:00 -0000 From: Keith Seitz X-X-Sender: To: Subject: Re: [patch] Fix expect build under cygwin + Tcl/Tk 8.3 In-Reply-To: <20020715175955.GB27999@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-07/txt/msg00334.txt.bz2 On Mon, 15 Jul 2002, Christopher Faylor wrote: > Again, expect is not supposed to be using the windows version of > anything. It is supposed to be using the cygwin/unix version. And this is the confusing part. There are actually TWO versions of tcl that are built for cygwin. One attempts to be windows, using windows-style pathnames. ::tcl_platform(platform) is "windows". The other attempts to be unixy. It has unix pathnames (afair) and ::tcl_platform(platform) is "unix". The former is the "real" tcl/tk for cygwin. Insight uses this DLL and import lib. Expect, however, uses the latter DLL. AFAICT, expect is the only client for this special DLL, and it is why we cannot disable builds in tcl/unix for cygwin hosts. Therefore, if there is really a problem with expect (which I also have not observed recently, but I will kick something off to double check), this patch appears to not be the real solution. Yes, it took me quite some time to figure all of this out! (Imagine my confusion when I would run tclsh, type "set ::tcl_platform(platform)" and get "windows", but I would run expect and get "unix"!) Keith