[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Path conversion documentation
From: |
Peter Rosin |
Subject: |
Re: [PATCH] Path conversion documentation |
Date: |
Mon, 30 Aug 2010 10:28:36 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 |
Hi Chuck!
Nice. Some nits below...
Den 2010-08-30 01:50 skrev Charles Wilson:
> +as a @code{$host} (MinGW) application, must set the @var{$PATH} variable so
> +that the true application's dependent libraries can be located -- but the
> +contents of the @var{$PATH} variable must be structured for MinGW. Libtool
> +must must use the WINE path mapping facilities to determined the correct
must must
> +Libtool uses @samp{cygpath} to convert from Cygwin (unix) paths to w32 format
> +when @code{$build} is Cygwin and @code{$host} is MinGW or MSVC.
Hmmm, $host is MinGW for MSVC as well as I'm sure you're aware. I don't know
how to reword it though...
> +tables" specified in <CYGROOT-N>/etc/fstab. Each each installation's
Each each
> +Unfortunately, WINE support for Cygwin is intermittent. Recent releases of
> +Cygwin (1.7 and above) appear to require more Win32 API support than WINE
> +provides at present; most Cygwin applications fail to execute. This includes
We should qualify exactly what versions of wine we are referring to.
Maybe "WINE provides at present (at least 1.3.1 and below)" or something like
that?
> address@hidden itself. Hence, it is best @emph{not} to use the LT_CYGPATH
> +machinery in libtool when performing linux to Cygwin cross-compiles.
> Similarly,
> +it is best @emph{not} to enable the Linux @emph{binfmt} support, because
> while
> +WINE will fail to execute the compiled cygwin applications, it will do so
> +while returning a status code of success. This tends to confuse build systems
Cheers,
Peter