[Patch] skipping import libraries for performance reasons - direct auto-import of dll's
Mon, 25 Nov 2002 11:28:01 -0500
Please separate policy arguments from functional arguments. Whether
cygwin/mingw should drop import libs is policy. Whether libtool should
use/create import libs is policy. Whether ld should support auto-import
when doing "link-directly-to-dll" is functional.
[Note: I haven't tested your patch, but it looks mostly ok]
I think the ability to do auto-import when using ld's virtual,
on-the-fly import lib feature (e.g. link-directly-to-dll) is valuable,
and complete support (once achieved) should be accepted.
There does not seem to be any support in your patch for the most recent
auto-import capabilities -- the runtime-pseudo-reloc stuff added by
Egor. So, if your patch is accepted as-is, then we have:
(1) if linking to implib, then "full" auto-import support is available;
--enable-pseudo-reloc allows auto-import of "complex" data (see ld.info).
(2) if linking directly to the dll without an implib, then "partial"
auto-import is available; --enable-pseudo-reloc has no effect. And
doesn't warn that it fails. I *think* you'd end up with a runtime
error, if attempting to import "complex" data.
(1) add support for runtime-pseudo-relocs to your patch, and resubmit.
You might want to work with Egor on this.
(2) When doing "link-directly-to-dll" AND a symbol has a non-zero addend
(e.g. "complex" data import), then behave as if
link_info.pei386_runtime_pseudo_reloc = 0, even if --enable-pseudo-reloc
has been specified. (Of course, IF --enable-pseudo-reloc has been
specified and the current link obj is an import lib, then psuedo-reloc
should occur). This complex behavior may actually be more difficult --
and more confusing -- than simply implementing solution (1).
Minor nit about patch format: watch out for your tab/indentation. It
doesn't match the surrounding text in many cases.
Note: yes, I realize that the runtime-pseudo-reloc stuff requires actual
runtime support (extra code in crt0.o for mingw, extra code in
cygwin1.dll for cygwin) which does not yet exist. But it will,
eventually -- and that's outside ld's purview. If "normal"
import-lib-based linking includes support for --enable-pseudo-relocs,
then "virtual on-the-fly direct" linking should support it too. Let
mingw/crt0.o and cygwin/cygwin1.dll take care of themselves. Downside:
it's hard for you, Ralf, test test whether you have properly implemented
the runtime-pseudo-reloc support for virtual on-the-fly direct linking,
unless you build your own cygwin kernel with the appropriate
support...talk to Egor...