This is the mail archive of the
mailing list for the Cygwin project.
Re: cyggfortran-3.dll broken ?
On 3/23/2011 12:57 PM, Dave Korn wrote:
> On 23/03/2011 16:35, Charles Wilson wrote:
>> And if you DO it this way, I'm pretty sure ld will go ahead and
>> create import entries in the .dll.a for them.
> Yes, that's what we'd want to happen isn't it? The import stub imports the
> symbol from libgfortran, the runtime loader finds it in libgfortran and
> performs the forwarding, everything Just Works. No?
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:
> Export Forwarding
> A particularly slick feature of exports is the
> ability to "forward" an export to another DLL. For example, in
> Windows NT®, Windows® 2000, and Windows XP, the KERNEL32 HeapAlloc
> function is forwarded to the RtlAllocHeap function exported by NTDLL.
> Forwarding is performed at link time
of the forwardING dll, not the client app.
> by a special syntax in the
> EXPORTS section of the .DEF file. Using HeapAlloc as an example,
> KERNEL32's DEF file would contain:
> HeapAlloc = NTDLL.RtlAllocHeap
> How can you tell if a function is forwarded rather than exported
> normally? It's somewhat tricky. Normally, the EAT contains the RVA of
> the exported symbol. However, if the function's RVA is inside the
> exports section (as given by the VirtualAddress and Size fields in
> the DataDirectory), the symbol is forwarded. When a symbol is
> forwarded, its RVA obviously can't be a code or data address in the
> current module. Instead, the RVA points to an ASCII string of the DLL
> and symbol name to which it is forwarded. In the prior example, it
> would be NTDLL.RtlAllocHeap.
So, if you simply drop in a new cygfortran-3.dll that has a forward for
(e.g.) cargf, then marco's CURRENT (and currently broken) octave will
suddenly start working.
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.
I think that would be the ideal situation, but it's obviously more work
than any other solution.
>> Or is it simply time to bump the DLL number for cygwin's gfortran runtime?
> Urgh. Don't want to diverge our DLL numbers from upstream if at all possible.
Well, you are removing a number of functions that cygfortran used to
provide. That's a backwards incompatible API change. So, under
ordinary rules that would require a version number bump. So, if you
made NO accommodation, then you'd really need to bump the vernum.
Unless you feel that given only one, or very few, major clients, that
it'd be "ok" to break the usual versioning rules for cygwin's fortran
runtime library, in the interests of maintaining your sanity.
OTOH, if you add forwarders or .drectives for the "removed" symbols --
whether corresponding thunks appear in the import library or not -- then
you wouldn't need to bump the vernum.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple