On Sun, 9 May 2004, Stas Bekman wrote:
> Yes, that sounds like a much better idea. There should be
> a way to tell the application that certain symbols will be
> resolved at run-time, and no matter who will provide them
> (application, another library or else). On AIX the linker
> is just as picky, but lets you shut up itself by telling
> it that the missing symbols will be resolved at run time
> and that it shouldn't worry about it. using the -brtl
> option (see lib/Apache/Build.pm).
There is a link option on VC++ 6, -delayload:some.dll, which
delays the loading of a dll until a function inside it is
actually called by an application. But this is used in
situations like
if (some_condition_is_true) {
call_the_dll_function();
}
else {
do_something_else();
}
where the dll may not be available on some target machine.
What seems different on Windows compared to Unix, even with
this delayload thing (which still requires you to link
against the .lib file corresponding to the relevant .dll),
is that when you link against a .lib file which resolves
symbols, information about those symbols appears in the
result which contains references to the specific dll where
those symbols appear. What Jan suggested, in some sense, is
to try to fool Win32 by building, eg, APR.so, in a way to
make it go by the name of mod_perl.so, by using the same
.def file for both (and specifying a library name). But this
doesn't seem to quite work, at least in a simple way.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
