X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-0.3 required=5.0	tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,TW_BG,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Message-ID: <COL102-W1396944213A30C6779785EB5B70@phx.gbl>
From: Karl M <karlm30 AT hotmail DOT com>
To: <cygwin AT cygwin DOT com>
Subject: FW: cyggfortran-3.dll broken ?
Date: Wed, 23 Mar 2011 11:17:47 -0700
In-Reply-To: <COL102-W3605F958314136F1E27881B5B70@phx.gbl>
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>,<4D8A32B6 DOT 9050507 AT gmail DOT com>,<COL102-W3605F958314136F1E27881B5B70 AT phx DOT gbl>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-IsSubscribed: yes
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



> Date: Wed, 23 Mar 2011 17:49:42 +0000
> From: dave.korn
> Subject: Re: cyggfortran-3.dll broken ?
>=20
> On 23/03/2011 17:31, Charles Wilson wrote:
>=20
> > 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:
>=20
> 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.
>=20
> > 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.
>=20
> 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 a=
pps
> linked against libgfortran should also continue to get their math functio=
ns
> from there rather than cygwin1.
>=20
> We'd want to keep the forwarders in place forever, and here's the good th=
ing
> 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.
>=20
> 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.
>=20
What if you just put the functions back in until the next gfortran dll vers=
ion bump?

...Karl=20=09=09=20=09=20=20=20=09=09=20=20

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