Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3CC9C213.5060002@ece.gatech.edu>
Date: Fri, 26 Apr 2002 17:09:39 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
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>
Subject: Re: ordinal linking for cygwin ld
References: <00db01c1eb76$239e4dd0$651c440a AT BRAMSCHE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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