X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.4 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_YG
X-Spam-Check-By: sourceware.org
Message-ID: <4DFCAF62.2010006@cwilson.fastmail.fm>
Date: Sat, 18 Jun 2011 10:00:02 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Bug with paths containing double slashes after double dot after a mount point
References: <E1QXeGw-0005zV-5X AT smtp DOT tt-solutions DOT com> <4DFBC1D2 DOT 4090207 AT ronin-capital DOT com> <loom DOT 20110617T231522-545 AT post DOT gmane DOT org> <4DFBCCB7 DOT 2080408 AT sbcglobal DOT net> <loom DOT 20110618T002902-783 AT post DOT gmane DOT org> <D255ECB130623742B0975B8F16C166C3578C1C3B56 AT LM-EXCHANGE DOT lifemodeler DOT com> <20110618083139 DOT GL3437 AT calimero DOT vinschen DOT de> <loom DOT 20110618T131403-874 AT post DOT gmane DOT org> <20110618113346 DOT GN3437 AT calimero DOT vinschen DOT de>
In-Reply-To: <20110618113346.GN3437@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 6/18/2011 7:33 AM, Corinna Vinschen wrote:
> cygpath -pm `some-mingw-g++ -print-search-dirs`

As the OP stated, this is happening deep inside libtool, so it's not
like he can easily insert a call to 'cygpath' in there.  Now, libtool
DOES have some limited support for environments where path formats
differ between the build system and the compiler -- specifically, for
using the native mingw gcc from cygwin -- but you have to take some
special steps to activate it. (By default, when libtool is configured,
it naturally assumes that --build=i686-pc-cygwin --host=i686-pc-mingw32
means 'use the cygwin-hosted mingw cross compiler' and does NOT activate
this path support for the tools, because it is assumed the toolchain
itself understands cygwin paths).

See
	info libtool 'Cross compiling'
	info libtool 'File name conversion'
	info libtool 'Cygwin/Windows File Name Conversion'
and finally
	info libtool 'Cygwin to MinGW Cross'
(you want the 'fake' scenario).

Basically, what you have to do is this:

	export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
	export PATH="/c/MinGW/bin:${PATH}"
	configure --build=i686-pc-cygwin \
        	--host=mingw32 \
        	NM=/c/MinGW/bin/nm.exe
	
Which does a number of things: (1) it activates the filename conversion
logic but ONLY for the paths that libtool feeds to the compiler tools,
(2) it ensures that the mingw.org compiler is used by forcing the name
'mingw32-gcc.exe' etc, and (3) ensures that the other mingw utilities
are found first in the PATH.  (4) Finally, there's something special
about $NM, but I forget what.

> Other than that, I fixed that in CVS.  It's a Win32 path coversion problem
> which only occurs if there are multiple backslashes trailing a ".." path
> component.

Yay!

--
Chuck


--
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