X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,EXECUTABLE_URI,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: References: From: Hugh Myers Date: Fri, 22 Oct 2010 05:06:42 +0000 Message-ID: Subject: Re: resolving directories To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Much thanks for the information. I did shudder before I implemented this 'solution' and agree that if I'd known, your approach would have been very much cleaner--- for that matter had I known, I would have upgraded the machine to match the source box and life would have been without this little speed bump. Thanks again! --hsm On Fri, Oct 22, 2010 at 5:01 AM, Andy Koppe wrote: > On 21 October 2010 21:56, Hugh Myers wrote: >> In a recent comedy of errors, I moved an executable from one machine >> to another. I was at least bright enough to move its associated .dll >> and even the .a for good measure. Not to surprisingly this did not >> result in a working program. After some thought I determined that the >> difference from one cygwin environment to another was the problem. >> Given a two year difference this seemed like the culprit. >> Unfortunately now is not a good time to upgrade the target machine, so >> I cheated and copied the first machines cygwin1.dll (isolated in the >> same directory along with the executable) to the second machine--- >> happiness ensued! > > Just to be clear: such a Frankenstein setup is utterly unsupported. > > If that machine really can't be upgraded properly, a better approach > might have been to install Cygwin 1.5 alongside 1.7 on your > development machine, by pointing http://cygwin.com/setup-legacy.exe at > a different base directory, and use that to build your program before > moving it across. Or just build it on the other machine in the first > place. (This is assuming you've got the source of course.) > > Cygwin 1.5 of course is now also unsupported, but at least it's proven it= self. > > >> Sort of. My executable while it worked, was unable >> to resolve a simple path like /usr/data/files_that_it_needs. Rather >> than giving in to despair, I idly thought to try >> /cygdrive/c/cygwin/usr/data/files_that_it_needs--- worked like a >> charm. >> >> So with that as background would I be correct in that one of the >> significant differences from version 1.5.25 to version 1.7.7 might lie >> in directory resolution? > > Yes: http://cygwin.com/cygwin-ug-net/ov-new1.7.html#ov-new1.7-file > > Andy > > -- > Problem reports: =A0 =A0 =A0 http://cygwin.com/problems.html > FAQ: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://cygwin.com/faq/ > Documentation: =A0 =A0 =A0 =A0 http://cygwin.com/docs.html > Unsubscribe info: =A0 =A0 =A0http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple