This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin 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


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


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