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


Charles Wilson writes:
> > Any comments ?

> Yes: compatibility.  The problem with ordinal linking is, suppose
> version 1 of a DLL has the following exports:
>
> func_one  @1
> func_two  @2
> var_one DATA @3
>
> and you link your executable to that dll by number.
>
> Now, the vendor releases a new version of the DLL with an additional
> data export.  Since no interface elements have been changed or removed,
> only added, your app SHOULD be compatible with this DLL.  But, if the
> vendor isn't careful, the new DLL could end up like this:
>
> func_one @1
> var_two DATA @2
> func_two @3
> var_one DATA @4
>
> 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.

> There's one big problem with that:
>
> def file are a @!#@^%@ to maintain.  You *always* forget to add
> something -- upstream maintainers are absolutely horrible about NOT
> documenting all of the new functions/data exports that they add.  So you
> end up building the DLL with auto-export, use objdump to list the
> exports, sort 'em, eliminate against your old .def file, create a new
> .def file....
>
> It's just a PITA.  And one time, back when I was using .def files, I
> actually managed, even with all of that effort, to release a DLL that
> dropped one of the exports the OLD dll had, and broke everybody's app.
> And I only deal with about 20 packages and DLLs.
>
> I shudder to think of maintaining all of that for the 200-odd DLLs that
> come with KDE.

Using def files is unusable.

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

> IMO, the better "solution" is to provide a pre-load app, to load all of
> the core KDE dlls into memory at bootup.  This is what Netscape/Mozilla
> now do, and what MS has been doing with IE for years: hide the load time
> during the bootup sequence; at least that way, KDE/Moz/Ntsp/IE doesn't
> get the blame...

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.

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.

Ralf





> --Chuck
>
>


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