On Wed, 5 May 2004, Stas Bekman wrote:
I did some more tweaks and this time generated the source scan. Here is the updated version: http://apache.org/~stas/apr-ext.patch
Thanks for that, Stas! There's a couple of things on Win32 (I'm not sure how specific they are to Win32):
- the WriteMakefile sub of ModPerl::BuildMM includes by default linking against $build->modperl_libs. This results in a dependency on mod_perl.so for, eg, APR::Pool. Something like this: ==================================================== Index: BuildMM.pm =================================================================== RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildMM.pm,v retrieving revision 1.15 diff -u -r1.15 BuildMM.pm --- BuildMM.pm 4 Mar 2004 06:01:06 -0000 1.15 +++ BuildMM.pm 7 May 2004 05:31:41 -0000 @@ -77,7 +77,9 @@ } }
- my $libs = join ' ', $build->apache_libs, $build->modperl_libs; + my $outside = join '|', qw(APR::Table APR::UUID APR::Pool APR::PerlIO); + my $libs = join ' ', $build->apache_libs, + ($args{NAME} =~ /^$outside$/ ? '' : $build->modperl_libs); my $ccflags = $build->perl_ccopts . $build->ap_ccopts;
my @opts = ( ==================================================================== would avoid this, but ...
Hmm, what kind of dependcy is that? How can I reproduce it?
On linux it doesn't depend on mod_perl.so at the moment:
% ldd blib/arch/Apache2/auto/APR/Pool/Pool.so
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /lib/tls/libc.so.6 (0x4001d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)- Even with the above, I get some fatal errors with unresolved symbols; for example, modperl_hash_tie, when building APR::Table. If I understand things correctly, this would get resolved at run time by loading APR, but I'm not
Correct. APR.so has these symbols.
sure how to tell APR::* at build time that this will be resolved later. One possibility is to do like is done for APR - copy all the necessary src/modules/perl/*.[ch] files to the build directory of the relevant APR::* modules, but this seems like unnecessary duplication. Another possibility is to perhaps just link the APR::* modules against the relevant src/modules/perl/*.o object files that already have been built at this point?
That will explode probably explode everything. If not it'll be horribly inefficient, since they aren't shared objects.
Did I mentioned already that windows ... :)
So, please explain to me and show what does windows do when building Pool.o and linking Pool.so. Thanks!
__________________________________________________________________ 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]
