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
