On Thu, 6 May 2004, Stas Bekman wrote: > Randy Kobes wrote: > > 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)
I'm not sure how to reproduce it on linux, but on Win32, the equivalent to ldd shows a dependency on mod_perl.so, when mod_perl.lib is included when linking. I think this comes about because VC++ finds the missing symbols in mod_perl.lib, which in this case just tells it how to get them from mod_perl.so - it doesn't know that these will be included later in APR. > > - 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! If I leave the linking in to mod_perl.lib, then Pool.o builds fine, but requires mod_perl.so. If I take out the linking to mod_perl.lib, then the build fails because modperl_interp_unselect is missing. This particular problem can be avoided by copying the workaround in APR.xs to APR__Pool.h. However, a similar problem arises with APR::Table - it builds OK when linked against mod_perl.lib, but this again creates a dependency on mod_perl.so. Removing mod_perl.lib from the link stage results in a build failure due to modperl_hash_tied_object not being found (which is in modperl_common_util.c, but APR::Table doesn't know that this will come later from APR). -- best regards, randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
