This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ordinal linking for cygwin ld


Ralf Habacker wrote:


> Any comments ?


Yes: compatibility.  The problem with ordinal linking is, suppose 
version 1 of a DLL has the following exports:

func_one  @1
func_two  @2
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:

func_one @1
var_two DATA @2
func_two @3
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 
file.

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 
.def file....

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

--Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]