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
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
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
Date: Sat, 27 Apr 2002 02:20:25 +0200
Message-ID: <006601c1ed81$53840690$625d07d5@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
In-Reply-To: <3CC9DAB9.60701@ece.gatech.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

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

Wait for the rules in my next mail. 
> 
> >>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?
> 
We will have to look at this a little deeper. 

Ralf