On Jun 12, 2013 11:53 AM, "Rainer Emrich" <[email protected]>
wrote:
>
> 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
Not having to cross compile is probably the biggest reason why msys even
exists. It would be far better however if Alex's efforts went directly
into cygwin so that it could support this "native mode".
------------------------------------------------------------------------------
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
