Mail Archives: cygwin/2008/08/05/22:58:32
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/
- Raw text -