compilation - cygwin -mno-cygwin-flag

[Charles Wilson]

Jay wrote:

> Can the ABIs be unifed?

No.

You're missing the point: the "mingw" personality uses the Microsoft C 
Runtime library (msvcrt.dll) -- in all of its microsoftian "goodness".

The cygwin gcc compiler, in its normal mode, compiles cygwin programs 
that use the cygwin runtime library (cygwin1.dll) in all of its posixy 
splendour.

These are very different things and they behave very differently. And 
you can't have a single program relying on two different runtime 
libraries -- not even transitively.

Note that the same is true of MSVC: either all of the DLLs/libs used by 
your program -- and the program itself -- are compiled against the 
multi-threaded runtime DLL (msvcrt*.dll (cl.exe switch /MD), or all 
against the multi-threaded runtime static library libcmt.lib (cl.exe 
switch /MT), or all against the single-threaded runtime static library 
libc.lib (no explicit cl.exe switch).

I omit the debug versions of those three runtimes, but you can't mix 
them, either. So, there are six different "universes" that your code can 
live in -- and it can't straddle any of them. I'm also ignoring the 
complexities involved in the variations of these six runtimes between 
Visual Studio 2003, 2003sp1, 2003sp2, 2005, and the various hotfix patch 
levels of each -- and each compiler variant has its own version of the 
six universes.  So, there are literally hundreds -- and all of these 
universes are distinct. Your code must inhabit exactly one.

At least with cygwin, there are only two universes to worry about: 
cygwin, and not-cygwin (== VisualC++6.0-era multi-threaded dll runtime).

>   line up struct stat, or make thin wrappers? 

We don't control MS's version of struct stat -- but suppose, for 
instance, that it does not support the latest fields specified by posix. 
However, cygwin strives for posix compatibility (or, more generally, 
"widely supported unix compatibility"). (And, if we tried to align with 
MS's definition, which one? vc6.0? vc7.0/2003, vc7.1/2003sp1? vc8.0/2005?)

So: either lobby Microsoft to conform to posix -- thus breaking THEIR 
abi backwards compatibility for all of their customers who are perfectly 
happy now and couldn't care less about posix.  Good luck with that.

Or, convince the cygwin team to abandon the whole purpose of the 
project: we shouldn't provide interfaces that are common on 
linux/unix/bsd/posix platforms so that software can be ported from unix 
to run on windows (cygwin) easily -- instead, we should just mimic 
visual studio -- well, some specific edition of visual studio.  Sorry, 
but no.

The same sort of argument applies to the rest of your issues. Cygwin != 
Windows. Windows != cygwin.

> ABI multiplicity bugs me..

If you want a uniform ABI between visual studio and gcc, then you should 
be using the MinGW compiler itself (and, stick with plain C code). 
That's what it is for. That is not what cygwin is for.

--
Chuck



--
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/