This is the mail archive of the
mailing list for the Cygwin project.
FW: cyggfortran-3.dll broken ?
> Date: Wed, 23 Mar 2011 17:49:42 +0000
> From: dave.korn
> Subject: Re: cyggfortran-3.dll broken ?
> 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.
What if you just put the functions back in until the next gfortran dll version bump?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple