Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 9 Mar 2005 19:21:31 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: req: using cygwin's gcc for creating static libs in msvc binary format (.a => .lib) # Re: static MSVC library? Message-ID: <20050310002131.GC19424@gully.bosbc.com> Reply-To: cygwin AT cygwin DOT com References: <20050309173223 DOT 505222101B7 AT warserver DOT warande DOT net> <20050309173442 DOT GB16830 AT gully DOT bosbc DOT com> <422F4DBA DOT 7020501 AT buddydog DOT org> <20050309200112 DOT GA17199 AT gully DOT bosbc DOT com> <422F63F7 DOT 2080100 AT buddydog DOT org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <422F63F7.2080100@buddydog.org> User-Agent: Mutt/1.5.6i 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/