X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <COL101-W18520135FFBF5B6C9AA52DE6740@phx.gbl>
From: Jay <jayk123 AT hotmail DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: ABI unification / non-x86 ports
Date: Fri, 8 Aug 2008 06:26:11 +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 m786R4KG018017


Clarification:

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

Compiled and statically linked the same.


There are multiple factors.

There is which compiler you use. That actually tends not to matter.
   Unless the headers use language extensions not supported.
   Or if the compilers actually output different formats, that the linkers
    did/did not understand. That is the case for the debug info presumably,
    but not for the code.
   Actually, there is a reason you can't always mix gcc+link or cl+ld.
    That is because "__ImageBase" has a different name between the two linkers.
    So if you use that symbol, your source is stuck with a particular compiler and linker.
    Unfortunate. This is why, e.g. MS link can't use Cygwin libc.a or such, because
    it has a use of the GNU/Cygwin symbol analogous to __ImageBase but
    differently named.


There is which headers to you use. Ideally they'd be "the same".
  But they aren't, and that is "the problem" (or just how things are).

The static .libs you use. With in any one invocation of the linker, you can
  only use either Cygwin libc.a, or Microsoft msvcrt.lib (or libcmt.lib, ignored).

IF the headers were "the same", then you could mix .objs within the static
  link that were compiled with either headers.

As well, there is what happens at runtime.
Given the varying headers, there is an analogous lack of interop there too.
Granted, though I kind of said the opposite before.
Folks can still traffic in int and such, but if they pass around FILE*,
trouble is likely. Really, it's about trafficing in types for which you
agree to the definition, for which you used the same headers.
And for opaque types, assuming sizes match (e.g. FILE*), which are
fed down to the same underlying layers.

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