Mail Archives: cygwin/2005/03/09/19:21:48
On Wed, Mar 09, 2005 at 04:00:39PM -0500, Jonathan Arnold wrote:
>I added that because there could be a specific switch that would
>obviously make it compatible. But in the absence thereof, I firmly
>believe my statement to be true, and have experienced it over many
>years of programming, across many different platforms and compilers.
You're doing it again. You talking about your "belief" when you have no
specific knowledge. I have specific knowledge. And, I'll bet I have
more years of programming under my belt, too.
>Oops, excuse me. I guess I didn't think it necessary to qualify the
>above statement, so I will here:
>
>==
>You cannot intermix non-trivial C++ (and, in many cases, even C) object
>files between compilers.
>==
The C++ limitation is well known, documented, and unavoidable. C,
however, doesn't suffer from the same name mangling problems.
When people find problems with compatibility with Windows calling
conventions in gcc they are considered to be bugs and they are
eventually fixed. The same is true for the object file format and for
the archive format. There doesn't have to be a specific switch or some
such because interoperability is a design goal for C and binutils.
(I'm speaking from my knowledge due to my position as the maintainer for
the windows ports of gcc and binutils.)
>>In fact, I just tried it. I created two MSVC object files, put them
>>in a .lib, and linked them with a program that I compiled using
>>gcc -mno-cygwin.
>
>Oops, excuse me. I guess I didn't think it necessary to qualify the
>above statement, so I will here:
>
>==
>You cannot intermix non-trivial C++ (and, in many cases, even C) object
>files between compilers.
>==
Hmm. I guess I didn't think it was necessary for me to write a
complicated program to prove my point.
>I'm not saying that it can't be done in some specialized circumstances,
>for some short period of time. But before long, you *will* get bitten
>by an incompatiblity. The Standard says nothing about object file formats,
>internal structures, name-mangling, stack usage, and so on. And that
>nearly guarantees disaster.
No. It won't. gcc/ld/ar are meant to interoperate with standard
windows object files and with standard windows libraries. I'm not
saying the functionality is perfect. It actually has improved in this
regard since 1999 and it gets a little better every year. There is no
need to avoid doing this nowadays.
Mixing *runtimes* is what Mumit Khan was talking about all of those
years ago and, so, yes, for the 5299427th time, you can't mix cygwin
objects with native windows objects when the native windows objects use
the windows runtime (msvcrt) and expect to get a running program. There
is no reason (modulo bugs in either gcc or msvc) why you can't mix "gcc
-mno-cygwin" (aka mingw) objects, however.
The calling conventions (and stack usage) for any objects that gcc
produces have to be the same as produced by the "native" compiler or you
wouldn't be able to call win32 api functions from gcc-built programs.
The naming convention, ditto.
I am not claiming that there are no bugs in gcc nor am I claiming that
every attempt to link will be problem free. We don't have as many
testers for this type of thing as we do for pure mingw or pure cygwin
linking. There is just no need to raise alarm bells about this to
discourage anyone from even trying this. We've seen at least a few
people in this mailing list who have linked gcc objects into their msdev
projects.
Of course, neither calling conventions nor naming conventions nor stack
usage nor linkability have anything to do with what the OP was asking.
His original email said:
"How comes is it impossible to write a STATIC lib using msvc's .LIB
format ? while .DLL are possible ?"
Since MSVC understands the output of cygwin's "ar" command quite nicely
(and has understood it for almost a decade), you can use it to create a
foo.lib. I was relying on this feature of ar in 1997 and, again, the
functionality and compatibility have improved since then.
cgf
--
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 -