Thu 31 Jan 2008 12:24:42 PM UTC, comment #5:
> I thought the "msvc" part of the i586-pc-mingw32msvc triplet
> referred to the MSVCRT.DLL runtime, not the MSVC compiler?
The Cygwin package uses the triplet i586-pc-mingw32. MSYS does
the same. If the Debian cross package yields the same kind of
executables than these two, there is no reason for it to have
a different triplet. If, however, the Debian cross package
yields different executables and libraries, I don't want to
hear about it. Then it's an unsupported platform.
> I am not so sure about the recommendation to use Cygwin in the
> README.woe32. Sure, if one is extremely careful, it should work
> fine to use Cygwin and its gcc -mno-cygwin to build non-Cygwin
> code. But my personal experience is that this is very likely
> to accidentally get you into a confusing state where you mix
> Cygwin headers and non-Cygwin headers, or even mix Cygwin
> libraries into non-Cygwin executables.
Sure, I agree with you that if you are not careful, you can
more easily mess up your environment in Cygwin than in MSYS.
But there's an explicit warning against this problem in
gettext's README.woe32.
MSYS is also supported as a build platform by gettext, but is
not recommended. I cannot recommend it due to the amount of
hacks that are in the MSYS runtime.
> MSYS was created exactly to avoid that kind of problems, and to
> avoid the need to manually use `cygpath -w foo` here and there.
> MSYS does the pathname translation on command lines
> automatically, and translates pathnames in environment
> variables. (When invoking non-MSYS programs, like the native
> mingw compiler.)
MSYS also does pathname translation in command-line arguments:
it converts "nul" to "/dev/null" (or vice versa, I don't
remember) when it finds it appropriate. In command-line
arguments!!
MSYS also causes pipes in bash to behave differently when
run inside rxvt. See the groff mailing list for multiple
reports of this bug.
Hope you understand why I cannot recommend MSYS.
Regarding the Debian cross package. Sometimes it is used with
a library called "libgw32c". of which people say
"Use of LibGw32c as a separate development library is very
complicated."
http://gnuwin32.sourceforge.net/packages/libgw32c.htm
That's the second reason why I don't want to hear about
problems with this build environment.
|