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: ABI unification / non-x86 ports


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


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