This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: compilation - cygwin -mno-cygwin-flag


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]