Mail Archives: cygwin-apps/2002/04/26/18:55:20
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
- Raw text -