[...]On Fri, 7 May 2004, Stas Bekman wrote: [ ... ]
We want mod_perl_base to be linked statically to APR.so and mod_perl.so (that's what my patch does at the moment, but instead it links 3 .o files). So how do we make windows compiler find the symbols from the base, when building APR:: objects? What we want to tell the compiler that is that the symbols are in mod_perl_base.lib, but they may be found in mod_perl.so or APR.so. Can we do that?
Think of APR.so as an equivalent of mod_perl.so, which doesn't require httpd. So for example APR::Pool may find its symbols resoved in mod_perl.so or APR.so depending on which is loaded. Do you think we can arrange such a thing?
I think it's possible using function pointers - here's an example (if nothing else, for the benefit of the archives :)
Apart from the gymnastics of the implementation, does this approach sound worth persuing? I guess one advantage here is that, for Win32, one has to define just the symbols (as function pointers), and then try loading either APR.so or mod_perl.so - one doesn't (I think) have to split mod_perl.lib up into separate libs, according to whether or not ap_ symbols appear.
Thanks for the example, Randy. That sounds like an overkill to me. And a hell of maintenance.
I asked Jan Dubois if there was a simpler approach - he
suggested something just involving manipulating the link
options and what appears in the .def file, but I can't get
it to work by just loading one of the dlls ("a" or "b" in
the above example). I'll look at that more closely, though.
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).
So AIX is going to have the same issue, but since now it's told to ignore unresolved symbols at linking time, it probably will survive this change.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
