-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
- --
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJRuJTKAAoJEOs4Jb6SI2CwLwoIAL6GWU8LrXwO5WWvmlGzK/RF
U+PRw62X9WVkyMY1IvHtHoMPlXjuAuphbZtH7NQGspECZtdUQLyQfacD47IvavGz
jDQVXLUe4SdwQVcv4QLVOr3KC4YY0QFZqBfis3e8egRGqoHfI28+WynJU9X463CC
RIC9FjkqwBI8kUqbTe/5hZ5bmxf1ifjyx19Z9QF+9qkexn3NihyMXRwtWey+xRwc
j8QS1/TArbwGvXGULaH/8bdpn1DSX/ILN8KjAt0sjQV0Uf0dwVaIcszHHAkAao4X
4s2w/Ffqt2848kry2wp4C2OxL8+8iRcGUylYDgzCd4oA1XO09uaUQ4DluS1oLF4=
=HQww
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
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
