Mail Archives: cygwin/2003/10/13/17:32:55
> >well, I'd expect to see the mingw application choke if I ran it through
> >cmd.exe this way..
> >
> >I don't see why it would have to choke if it ran through *SH.EXE* this
> >way. sh.exe - in either the mingw32 world or the the cygwin world - could
> >handle the arguments. And that way, interoperate a lot better with Win32.
> >
> How (and why) should sh.exe convert anything for the program it's about
> to exec? To do that it would have to be cognizant that this is a MingW
> executable and therefore needs conversion of such things as pathnames.
> How would it know that the underlying executable did not want
> "Date/Time" as a string as opposed to some sort of filename? The shell
> shouldn't been guessing and converting things like this because it just
> doesn't know enough to guess right.
touche.. although you could use a mechanism like 'complete' in tcsh to
enforce the conversion (complete recognizes things like paths, ip addresses,
email addresses, etc.) and enforces conversion by this mechanism. This would
work in 95-99% of the cases.
> Really? How so? 'Cause I'm still able to use -mno-cygwin and produce
> Windows only executables. Are you not able to do this? If not then why?
Like I said, try:
mingw > gcc -dM -e -xc /dev/null
cygwin > gcc -mno-cygwin -dM -E -xc /dev/null
cygwin makes 73 defines, mingw makes 38. If a large project uses any of the
cygwin defines, it will behave differently than if compiled with native mingw.
As I said, this is just the tip of the iceberg - who knows what patches that
mingw has made to gcc, ld, make, etc. which could affect the building and
running of large win32 packages.
If the large packages built in mingw are tested via mingw, then mingw is the
only real way to a 'proper' win32 executable. And the only way to truly
emulate mingw32 would be by merging it.
> Maybe the MingW package in Cygwin needs to be updated, however, I fail
> to see the need for a MINGW or NO_CYGWIN flavor aside from what
> currently exists (i.e. -mno-cygwin).
Because gcc is not the only place that has MINGW-isms in it; msys departs from
the cygwin standard and handles certain things differently. In order
to build MinGW packages right, the underlying tools have to work the same
as well.
MINGW and/or NO_CYGWIN simply wrap all of this up in a nice user friendly
package.
Ed
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -