httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <ra...@theoryx5.uwinnipeg.ca>
Subject Re: [mp2 patch] getting APR to work w/o modperl
Date Fri, 07 May 2004 06:41:11 GMT
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

Mime
View raw message