From: Keith M. <kei...@us...> - 2006-12-08 12:20:19
|
On Friday 08 December 2006 00:54, Bob Rossi wrote: > The problem I see now is this: > > $ =A0i586-mingw32-gcc.exe -g -O0 =A0 -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE > -I./include > -I/home/bobbybrasko/rcs/svn/official_cygwin_build/vigilant/builddir/vigil= an >t-tools/apr/include/arch/win32 -I./include/arch/unix > -I/home/bobbybrasko/rcs/svn/official_cygwin_build/vigilant/builddir/vigil= an >t-tools/apr/include -o passwd/apr_getpass.i -E passwd/apr_getpass.c > passwd/apr_getpass.c:22:25: apr_private.h: No such file or directory Right. You are using an i586-mingw32-gcc.exe which is a renamed copy of th= e=20 MinGW binary distribution. This is a *native* Win32 application, so it=20 simply cannot interpret the Cygwin style emulated POSIX paths you've passed= =20 it, in this command line. If you invoke this in MSYS, the MSYS variant of sh.exe automatically=20 transforms every POSIX style path you specify to its canonical Win32=20 equivalent. Cygwin doesn't offer you that assistance; you have to supply=20 *every* one of those -I paths in canonical form yourself, or use cygpath to= =20 perform the transformation. > $ =A0i586-mingw32-gcc.exe -g -O0 =A0 -DHAVE_CONFIG_H -D_LARGEFILE64_SOURCE > -I./include > -IC:/cygwin/home/bobbybrasko/rcs/svn/official_cygwin_build/vigilant/build= di >r/vigilant-tools/apr/include/arch/win32 -I./include/arch/unix > -I/home/bobbybrasko/rcs/svn/official_cygwin_build/vigilant/builddir/vigil= an >t-tools/apr/include -o passwd/apr_getpass.i -E passwd/apr_getpass.c So, here you've fixed just the one; all the others remain invalid, from the= =20 perspective of i586-mingw32-gcc. > Basically, the Cygwin autoconf is generating paths with /home/.... > instead of C:/...., I handcoded the C:/ path and that works. How did you > get around this in the past? It's not the Cygwin autoconf that's at fault, but rather the configure scri= pt=20 which just happens to be autoconf generated. This is one of those situatio= ns=20 where the package maintainer needs to make special provision for handling t= he=20 idiosyncrasies of the Win32 file system. Cygwin in particular, and also MS= YS=20 to some extent, present a particularly difficult scenario for package=20 maintainers, because they both try to hide the nastiness of the Win32 file= =20 system behind an emulated POSIX charade, and the difficulties are compounde= d,=20 for a cross compiling environment. =46or an example of how I've addressed *some* of the issues, you might have= a=20 look at the configure.ac and aclocal.m4 I wrote for the MinGW port of man: http://downloads.sourceforge.net/mingw/man-1.6-mingw-beta-1-src.tar.gz Regards, Keith. |