This is the mail archive of the
mailing list for the Cygwin project.
Re: Bug with paths containing double slashes after double dot after a mount point
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).
info libtool 'Cross compiling'
info libtool 'File name conversion'
info libtool 'Cygwin/Windows File Name Conversion'
info libtool 'Cygwin to MinGW Cross'
(you want the 'fake' scenario).
Basically, what you have to do is this:
configure --build=i686-pc-cygwin \
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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple