On Tue, 18 May 2004, Stas Bekman wrote: > Randy Kobes wrote: > > On Mon, 17 May 2004, Stas Bekman wrote: > > [ ... ] > > > >>Randy Kobes wrote: > >> > >>>I'll try it for Windows and see how much is involved; if > >>>this works as expected, it should just involve changing > >>>how things are compiled, as well as the order (APR.so coming > >>>first). But one of the joys of working with Windows is > >>>that things are never as expected ;) > > > > > > I've now tried it on Windows, and in particular the > > (patched) apr-ext tests pass. This though was manual; > > Great! > > > I'll next try to get things built automatically. But > > just for information, what was required was > > - adjust xs/APR/APR/APR.def to include > > modperl_interp_unselect > > modperl_hash_tie > > modperl_hash_tied_object > > modperl_perl_gensym > > modperl_error_strerror > > in the list of exported symbols > > We ought to automate that. I think you've missed symbols, > like tracing functions, since you didn't build with > tracing enabled or because the APR/Foo.o's that my patch > tests don't use tracing. We should probably look at the > the apache/apr DECLARE macros. Alternatively it can be a > common group of files modperl_common_*.c but it'll be hard > to extract those symbol names. Another approach is to > split the tables/ModPerl/Functions.pm (which I think > that's how .def is generated now). May be the function > names should have a different prefix than /modperl_/. In > which case it'll be clear that they are common ones.
No doubt I did miss some symbols - this was just a quick thing to see in particular if the apr-ext tests worked. I'll look at the Functions.pm - you're right that this is used to generate the .def file now. > > - build APR first, so APR::* can link against it (the > > default action is to build APR::* first); > > Really? Is it specific to win32? On linux with the current > cvs, I can run 'make -j' which builds things in parallel > and I was getting APR/*.so getting build while > src/modules/perl/mod_perl.so was still not built. But I > don't see problem with arranging what you did. Without building APR first, APR::* dies at the link stage about references to unknown symbols. I couldn't see the nmake equivalent to 'make -j', but I'll look - this must be a common problem. > > - adjust the Makefiles in APR::* to link to > > blib/arch/Apache2/auto/APR/APR.lib > > before linking to src/modules/perl/mod_perl.lib > > Good. > > > - add > > blib/arch/Apache2/auto/APR/ > > to the PATH, so APR.dll can be found (perhaps APR.dll > > [APR.so] should be installed to $APACHE2/lib or > > $APACHE2/bin, as appropriate?) > > That's not good. The whole idea was not to create a > library which will need to be searched by the loader. The > ideas was to have a plain .so which will live under perl's > lib, and loading any APR/Foo.pm will first load APR.so, > and then APR/Foo.so. So yes, there is a need to change the > autogenerated APR/*.pm files, but you shouldn't need to > mess with PATH or anything that has to do with system-wide > loader. > > If we were to create a separate .so (read: win32/dll), > that would be mod_perl_common.so since all these things in > modperl_common.* have nothing to do with apr. But we want > to avoid to impose that added enormous complexity on our > users. This fiddling with the PATH was just to get the tests working (one could also use a LoadFile "...APR.dll" directive to accomplish the same thing). There's probably some internal way to do that within APR::*, along the lines of loading APR.so within APR/Foo.so, so that users don't have to be bothered. > > In any case, no source code changes were needed - I think > > all the above can be done within the Makefile generation. > > It's fine to change the source if it's needed :) > > Good work, Randy! Thanks :) -- best regards, randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
