X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.2 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_BG,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: sourceware.org
Message-ID: <4D8A32B6.9050507@gmail.com>
Date: Wed, 23 Mar 2011 17:49:42 +0000
From: Dave Korn <dave DOT korn DOT cygwin AT gmail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cyggfortran-3.dll broken ?
References: <AANLkTi=WaAY1HY2bZ2zKHHuCkpNE4oLCZ8cY1J=CV1Ma AT mail DOT gmail DOT com>	<4D8A1775 DOT 5020601 AT gmail DOT com>	<4D8A1BCD DOT 2080506 AT gmail DOT com> <AANLkTinGfQi2ad4yTbDydrzbURQATtTT4zVJWG01V5LS AT mail DOT gmail DOT com> <4D8A214D DOT 6090409 AT cwilson DOT fastmail DOT fm> <4D8A2683 DOT 1010009 AT gmail DOT com> <4D8A2E5F DOT 1040204 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <4D8A2E5F.1040204@cwilson.fastmail.fm>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

On 23/03/2011 17:31, Charles Wilson wrote:

> Err...no, I don't think so.  Symbol forwarding is actually implemented
> as part of the PE-I386 spec, so it resides in the forwardING dll itself,
> not the import library, and is handled at runtime by the windows loader:

  Yes yes yes, you're jumping too far ahead; what I was pointing out is that
you still have to have an import stub in order to pull in the import from the
forwarding DLL.

> However, by NOT having a thunk present in the import library, then when
> linking a new client the symbol will be resolved by libcygwin.a and will
> show up in the new client's import list as coming directly from cygwin1.dll.

  Well that seems like it would be cleaner in theory, but it would still
constitute a change to the ABI exported by libgfortran, which is what we were
trying to avoid; if we're keeping the ABI constant, then future fortran apps
linked against libgfortran should also continue to get their math functions
from there rather than cygwin1.

  We'd want to keep the forwarders in place forever, and here's the good thing
about how it works: regardless which dll.a the import stub comes from and how
many DLLs it does or doesn't forward through before it reaches the actual
implementation, that's all indirected away by the loader and at run-time it's
still just a single indirect jump in both cases.

  Hmm, I should probably do this.  And send it upstream too.  But I'll
prioritise it lower than bringing newer compiler versions onstream unless we
start to get a lot of problem reports.

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple