> 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?
...Karl -- 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
