This is the mail archive of the
mailing list for the binutils project.
RE: ordinal linking for cygwin ld
- 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>
- Date: Sat, 27 Apr 2002 02:20:25 +0200
- Subject: 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.
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.
> >>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.