Am 12.06.2013 17:33, schrieb LRN:
> On 12.06.2013 17:50, Corinna Vinschen wrote:
>> On Jun 12 16:00, LRN wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> On 12.06.2013 14:47, Corinna Vinschen wrote:
>>>> Hi Алексей,
>>>>
>>>> On Jun 11 21:10, Алексей Павлов wrote:
>>>>> MSYS includes the following changes to Cygwin to support using
>>>>> native Win32 programs: 1. Automatic path mangling of command line
>>>>> arguments and environment variables to Win32 form on the fly for
>>>>> Win32 applications inside bash.exe
>>>>
>>>> That's a bash change which does not affect the underlying Cygwin/MSYS
>>>> DLL.
>>> You misinterpreted that.
>>>
>>> The mangling is done in msys-2.dll, it's done every time a process is
>>> spawned. The parent checks the dependencies of the child, and if child
>>> does NOT depend on msys-2.dll (that is, if child is not a MSYS
>>> application), the parent will spawn it with mangled environment (thus
>>> the child will not get POSIX paths in envvars, such as PATH) mangled
>>> and arguments
>
>> This is default in Cygwin for a long time. When Cygwin starts, a small
>> number of variables is converted from Windows to POSIX style, namely
>> PATH, HOME, LD_LIBRARY_PATH, TMPDIR, TMP, and TEMP.
>
>> If a Cygwin process execve's a non-Cygwin process, the whole thing is
>> done backwards.
>
>> This is not done for any other variable, and in no direction, because
>> trying to recognize other variable's content as path and then converting
>> it to the other style is pure speculation on the DLL's part. The result
>> is broken as often as not.
>
> I can't say anything about variables (i can easily imagine cases where not
> converting variables would break the build process, but i can't name a
> package that does need it - because i never tried to compile anything
> without that feature, and i don't remember it misfiring on me and
> converting something that shouldn't have been converted).
>
> However, the fact that command line arguments are not converted (at least
> you didn't mention anything about converting arguments; i assume they are
> left untouched; my googling also supports that assumption) means that
> command line arguments like these:
>
> -I/mingw/lib/glib-2.0/include
>
> /src/mingw-w64/mingw-w64-libraries/winpthreads/src/clock.c
>
> will not be converted, which makes it next to impossible to use W32 tools
> in conjunction with autotools (ok, the /src thing can be avoided by
> carefully using relative paths only, but i can't say how much things will
> slip past that and bite you, if mangling is switched off).
>
> You are also incorrect in assuming that the probability of MSys correctly
> guessing that something should be mangled is 0.5 ("as often as not", as you
> put it). In my experience, the probability of a correct guess goes up to
> 0.9 and above. The logic is quite complex (see [1] for the list of rules
> MSYS1 uses; see MSYS2 source for the list of rules MSYS2 uses). There ARE
> cases when you don't want MSys to mangle things, but it does anyway, and
> the result is unsatisfactory. In these cases buildsystem has to be
> patched.
>
> Mostly it's when something that looks like a path (such as a prefix, i.e
> "/mingw") is used in a construction like -DSOMEPREFIX="\"/mingw\"". The
> problem is solved by using config.h instead of -D (since the contents of
> files are not mangled). The reverse is also true - sometimes buildsystems
> will generate source files on the fly (usually - by processing .in files
> and substituting @VARIABLES@), and will insert absolute paths to files into
> generated code, i.e. fopen ("/src/libcdio/blah/blah/foobar.data", "r")
> (usually it's for testcases that are not designed to be relocatable
> anyway). This can be fixed directly (using relative names explicitly), or
> worked around by calling configure relatively (i.e. cd builddir ;
> ../srcdir/configure <arguments> - assuming that builddir and srcdir are
> siblings) when doing OOTSD builds (in which case all names will be relative
> no matter what).
>
> There are also selected cases where something looks like a path, but isn't
> one. One example that comes to mind is xmlcatalog.exe, which is given
> arguments like "-//OASIS//ELEMENTS DocBook Information Pool V4.2//EN",
> which look like paths, but shouldn't be mangled. The solution is to use
> msys version of xmlcatalog (that fixes some other problems as well) instead
> of mingw version.
>
> Same goes for git. As i mentioned earlier in this thread, one of the things
> that msysGit devs did to their fork of MSYS1 was to slightly alter the
> mangling code to not to mangle some things (some kind of git refs, i forgot
> the specifics). Again, this is fixed by using real msys-git that needs no
> mangling.
>
> But most of the time things "just work"™
>
> [1] http://www.mingw.org/wiki/Posix_path_conversion
>
To add a little bit to this discussion. I just did a native gcc
x86_64-w64-mingw32 3-stage bootstrap using the MSYS2 version dated 10.06.. It
worked out of the box, without any issues. That wasn't possible with the old
MSYS because of it's 32-bitness and it's impossible with resent cygwin.
Cheers
Rainer
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
