X-Recipient: archive-cygwin@delorie.com X-Spam-Check-By: sourceware.org From: "Dave Korn" To: References: <1218043716.30536.ezmlm@cygwin.com> Subject: RE: ABI unification Date: Thu, 7 Aug 2008 00:22:49 +0100 Message-ID: <005501c8f81b$575346e0$9601a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Jay wrote on 07 August 2008 00:07: > First, I meant a uniform compile time ABI. > Not an ability to mix and match at runtime. This thing ... > I simply want to compile two .objs with the different > compilers and headers, and then link them together, > trafficing in whatever. ... and this thing completely contradict each other. What's the use of being able to link them together if they don't work at runtime? > Anyway, given the errno.h mismatches, it's not possible without a > breaking change. It's pointless in either case. > Perhaps this can be "fixed" for any non-x86 Cygwin port? The very concept of a non-x86 Cygwin port is meaningless nonsense. You need to do a bit more homework. I suggest you start by reading the first sentence on the first page at http://cygwin.com/. It should explain to you why there's never going to be any "non-x86 Cygwin port". cheers, DaveK -- Can't think of a witty .sigline today.... -- 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/