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: <3CC9DAB9.60701@ece.gatech.edu>
Date: Fri, 26 Apr 2002 18:54:49 -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: Ralf Habacker <Ralf DOT Habacker AT freenet DOT de>
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: <006001c1ed6f$55809f10$625d07d5 AT BRAMSCHE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ralf Habacker wrote:

>>
>>Since your app linked by ordinal, it will break if you try to run it
>>with the new DLL, without re-linking.
>>
> 
> accepted
> 
> 
>>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.
>>
> 
> Or be relinking all the libs.


If *you* release new "compatible" libs with the ordinals different from 
the current libs, *my* application breaks.  Or, you might get ripple 
effects: what if I distribute a dll that depends on KDE's libs, and Bob 
has an app that depends on my dll?  Bob's app breaks because my dll is 
broken because you released new "compatible" libs.  Not good -- and it'd 
take a while to track the problem down too: (a) I need to relink my dll, 
and give it to Bob, and then (and only then) (b) Bob can relink his app.

Blech.


>>I shudder to think of maintaining all of that for the 200-odd DLLs that
>>come with KDE.
>>
> 
> Using def files is unusable.


Unless it's the only way to avoid the problems above.   Then, you ignore 
the pain and just do it -- or write code to do it for you, like the 
openoffice guys have done.


>>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,
>>
> 
> no, the symbol name was build from the undef section, if a corresponding
> _imp_symbol was found, that means from the client side. There was no access
> (except of the dll name) to the implibs data.


Okay...


>>not the symbol ordinal...
>>
> 
> I have patched auto-import stuff which got the ordinal from the implib.
> It works with the appended testcase. Currently I've build a new working qt with
> this.


> 
> In the second solution I have told about, using the regular implibs and decide
> on a per case base
> if ordinal linking or not.
> 
> I'm thinking about creating to areas, an internal and an external.
> New releases of kdelibs and perhaps kdebase for example are build together. So
> ordinal linking is not problem. -> internal area. Any other app may be linked by
> name -> external area.


Ah, so there'd be a special switch that KDE's internal makefiles use to 
turn on 'link by ordinal' behavior; other applications would not use it, 
and would thus link by name?  (or, they'd use it and link-by-ordinal at 
their own risk...)

That seems workable to me.

 
> Second some dll's are only for specific apps for example konqueror or kcontrol,
> which holds there code in some dll's. When rebuilding konqueror  the dll's could
> be linked ordinal without any problems, because there were all rebuild.


Errr...not so fast.  Code reuse -- konqueror dlls can be linked into 
other apps, can't they? -- or is all code reuse of that nature in KDE 
done via KParts/Bonobo/CORBA/whatever, and not actual linking?

--Chuck