Received: from mail2.ntp.org (mail2.ntp.org [204.152.184.138]) by krbdev.mit.edu (8.12.9) with ESMTP id lBL3bMHW028226; Thu, 20 Dec 2007 22:37:22 -0500 (EST) Received: from 65-86-158-146.client.dsl.net (65-86-158-146.client.dsl.net [65.86.158.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.ntp.org (Postfix) with ESMTP id 4C855399BD for ; Fri, 21 Dec 2007 03:37:16 +0000 (UTC) (envelope-from mayer@ntp.isc.org) Received: from cust-63-209-227-225.bos-dynamic.gis.net ([63.209.227.225] helo=[10.10.10.101]) by 65-86-158-146.client.dsl.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1J5Yfw-0000xH-Kb for rt@krbdev.mit.edu; Thu, 20 Dec 2007 22:35:52 -0500 Message-ID: <476B33D6.9080202@ntp.isc.org> Date: Thu, 20 Dec 2007 22:32:38 -0500 From: Danny Mayer Reply-To: mayer@ntp.isc.org User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: rt@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #5859] Build of windows/identity fails in clean directory References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Kostecke.net-Mailscanner: Found to be clean X-Kostecke.net-Mailscanner-From: mayer@ntp.isc.org RT-Send-Cc: X-RT-Original-Encoding: iso-8859-1 Content-Length: 1561 Jeffrey Altman via RT wrote: > Kevin Koch via RT wrote: >> The VS2003 build environment still works. It is the VS2005 >> environment that doesn't. Also, mkdir a\b\c\d creates the entire path >> when run from the VS2005 command window. I'll bet the difference is >> in the environment perl sets up for sys. How can I investigate this? >> [Does perl do different things for sys and backtick?] > > If you are using the same perl in both VS2003 and VS2005, why do you > believe that perl is at fault? > > You have the VS2003 and VS2005 shortcuts. Compare them and the > environments they produce and identify the differences. > > use tools such as procmon and procexp to determine what processes are in > use and what operations are being performed. > > in any case, it is clear this is a configuration issue not a makefile > issue. This ticket should in my opinion be closed and if you need help > from the kfwdev community, you should ask for help there. While I agree that this appears to be a configuration issue and not a makefile issue, the ticket should *not* be closed. The problem needs to be understood and resolved and it may very well require changes to the makefile to ensure that the right thing happens. Just because it only currently happens in one situation it doesn't mean that the code is not wrong. On an advisory note try running ntwhich on mkdir and see where it finds it. That may tell you why you are having a problem. If you need a copy, send me mail. I have a bunch of tools like that which are not cygwin based. Danny