Appropriate expectation on the degree of cygwin and MS interoperability
Neil.Mowbray@calgacus.com
Neil.Mowbray@calgacus.com
Fri Jan 1 12:07:00 GMT 2010
Folks,
A bit of a vague question but any greater clarity concerning the appropriate
level of interoperability between Cygwin and MS would be appreciated.
I have my Windows 6 and 7 platforms configured to build software using
different toolchains, the most common being (1) Visual Studio 10 and (2)
Cygwin with gcc-4.
When using the Visual Studio toolchain I will prefer a cygwin tool over a
MS tool, so for example, I always use bash and gnu make and never use the
cmd shell/power shell or nmake. Taking this further, I will try to use
nm over dumpbin and ar over lib.
For the most part the cygwin tools interoperate with MS artifacts but
it does break down, especially, with 64bit artifacts. For example, nm
can work with 32bit object files created by MS cl.exe but it cannot
work with 64bit MS object files (unrecognised file format).
The question is: how far should I expect the interoperability to go?
For example, is the fact that nm cannot handle 64bit MS object files
a (1) defeat in cygwin/nm or (2) I should be grateful that it works
with 32bit files and otherwise lower my expectation?
I suppose at its core the question is about the intent of cygwin. Is
it (1) to provide unix like capabilities to a MS platform (in which case
one would expect/demand a high degree of interoperability), or
(2) to provide a unix like island inside a MS platform?
The problem with (2) is one cannot really stay isolated from the
host MS environment.
My previous question of how/if one can use cyginw *.h *.dll *.a
artifacts in a MS compiled program is essentaily the same theme
although I have lower expectations that it is possible.
Any pointers?
Regards, Neil
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin
mailing list