This is the mail archive of the
mailing list for the binutils project.
Re: ordinal linking for cygwin ld
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: kde-cygwin at mail dot kde dot org
- Cc: Kde-Cygwin <kde-cygwin at kde dot org>, Binutils <binutils at sources dot redhat dot com>, Cygwin-Apps <cygwin-apps at cygwin dot com>
- Date: Fri, 26 Apr 2002 17:09:39 -0400
- Subject: Re: ordinal linking for cygwin ld
- References: <00db01c1eb76$239e4dd0$651c440a@BRAMSCHE>
Ralf Habacker wrote:
> Any comments ?
Yes: compatibility. The problem with ordinal linking is, suppose
version 1 of a DLL has the following exports:
var_one DATA @3
and you link your executable to that dll by number.
Now, the vendor releases a new version of the DLL with an additional
data export. Since no interface elements have been changed or removed,
only added, your app SHOULD be compatible with this DLL. But, if the
vendor isn't careful, the new DLL could end up like this:
var_two DATA @2
var_one DATA @4
Since your app linked by ordinal, it will break if you try to run it
with the new DLL, without re-linking.
So how does the vendor ensure that he doesn't unnecessarily break
backwards compatibility, and keep the ordinals the same? By using a def
There's one big problem with that:
def file are a @!#@^%@ to maintain. You *always* forget to add
something -- upstream maintainers are absolutely horrible about NOT
documenting all of the new functions/data exports that they add. So you
end up building the DLL with auto-export, use objdump to list the
exports, sort 'em, eliminate against your old .def file, create a new
It's just a PITA. And one time, back when I was using .def files, I
actually managed, even with all of that effort, to release a DLL that
dropped one of the exports the OLD dll had, and broke everybody's app.
And I only deal with about 20 packages and DLLs.
I shudder to think of maintaining all of that for the 200-odd DLLs that
come with KDE.
Then, there's one smaller problem:
If you use a .def file to generate your DLL, will the auto-import stuff
get added to it? Can auto-import even work, if you're linking by
ordinal -- I thought the _nm_ hints were based on the symbol name, not
the symbol ordinal...
IMO, the better "solution" is to provide a pre-load app, to load all of
the core KDE dlls into memory at bootup. This is what Netscape/Mozilla
now do, and what MS has been doing with IE for years: hide the load time
during the bootup sequence; at least that way, KDE/Moz/Ntsp/IE doesn't
get the blame...