X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <COL101-W67D365495CB0C80B0AEC65E6750@phx.gbl>
From: Jay <jayk123 AT hotmail DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: ABI unification / non-x86 ports
Date: Thu, 7 Aug 2008 23:17:02 +0000
In-Reply-To: <1218111628.8564.ezmlm@cygwin.com>
References: <1218111628 DOT 8564 DOT ezmlm AT cygwin DOT com>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id m77NHmmt013300


> non-x86 port 

 Yes, I know what the web page says. 
 And I've seen the code. Stepped through it. Read it. 
 I'm just hoping, ok? 
   Or maybe I can help. I know it's not easy. 
   And ABI unification is a nuisance upon already difficult work. 
 More for AMD64 than IA64. 
 And yes, I know x86 works on them. 

Are you being serious or sarcasting about wanting IA64?

> 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? 
 
Sorry, I was not clear.
.objs compiled differently *but statically linked the same*
should be able to communicate.

Like so:
ms.c:
#include 
void ms(const char* a)
 cygwin(fopen(a, "r"));

cyg:
#include 
  void cygwin(FILE* f)
  {
    fread(..., f);
  }

That example WILL (very very likely) work, since it does so little.
Assuming fopen/fread have no inline/macro component.
That they are both always completely function calls.
This is the interoperable world that some folks would like some of.


.dlls *statically linked diffferently* CAN AND DO communicate, but
only in certain ways. Counter example: Like the above.
Example: replace with CreateFile/ReadFile, since I'm talking about
static linking to one C/Posixy runtime or another, and there is only
one underlying CreateFile/ReadFile.
This is the real world with dynamic linking.


.dlls *statically linked the same* CAN communicate in "all" ways.
This is the simple world folks generally stay within.


It's not really a binary thing, in that there are factors besides Cygwin.
For example, if you define _WIN32_WINNT differently, some structs
in windows.h change size. I think that's gross but oh well.
If one guy passes a pointer of his to another, compiled with a different #define,
without specifying the size, and the other copies to or from it, can crash.


It's a combinatorial explosion unfortunately.
You are left trying to match up "as much as possible", not being certain
what matters and what doesn't.
Some folks (boost) provide .libs/.dlls built multiple ways, so they can
interop with "any" kind of client. What an unfortunate cost.


 - Jay

--
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/