On Dec 24 00:57, "Philip M. Gollucci" <pgollu...@p6m7g8.com> wrote: > > Subject: Re: [mp2] undefined symbol in make test with threaded Apache 2.2.11 > > cr...@animalhead.com wrote: > > Neither mod_perl 2.0.4 nor the current build modperl-2.0_20081223052020 > If you're going to do that 'current build', I'd use revision numbers of SVN > instead of the data.
The page on the mod_perl site about "what to do before submitting a problem report" suggested trying the current build from the location I used, as a data point for the overall report. So I complied with those instructions. If some other source is better, perhaps the web page in question wants editing. > > > "PL_markstack_ptr" > This isn't perl 5.8.8 vs perl 5.8.9 related, if you diff the trees, only 1 > line is changed > - *PL_markstack_ptr = (p) - PL_stack_base; \ > + *PL_markstack_ptr = (I32)((p) - PL_stack_base);\ "PL_markstack_ptr" is in the error message that occurred. Perhaps it's no longer exported, or global'ed, or whatever the right term is nowadays? > > MP_APXS => /usr/local/apache2/bin/apxs > > *** /usr/local/apache2/bin/httpd -V > You did not install www/apache22 port, but rather compiled by hand ? It has been years since I compiled or assembled anything by hand, but I do go back in the software field to 1963, when such things were sometimes still done. All of several set of instructions I have read, as to how to build mod-perl, have recommended the apxs method. > > > *** /usr/local/bin/perl -V > > Summary of my perl5 (revision 5 version 8 subversion 9) configuration: > So this isn't in the ports tree yet, so you also compiled perl by hand I have never had anything to do with the ports facility, and have built all of our site's software from source for years. The build sequences used for Aapche 2.2.11, perl 5.8.9, and mod-perl 2.0.4 have all been used on previous occasions with full success. The big change is building 2.2.11 for the event MPM. > > > @INC: > > /usr/local/lib/perl5/site_perl/5.8.9 > > /usr/local/lib/perl5/site_perl/5.8.8 > > /usr/local/lib/perl5/site_perl/5.8.7 > > /usr/local/lib/perl5/vendor_perl/5.8.9 > > /usr/local/lib/perl5/vendor_perl/5.8.7 > Looks like your perl tree has some history, I'd try with a clean tree .. my > money is here. The Perl5.8.9 in question has worked very well with the previous prefork Apache 2.2.10 and a mod-perl built against it. A "clean tree" approach is complicated by the fact the tree has essential modules in it from my internet hosting provider (IHP), mostly in the vendor-perl branch but perhaps in other branches as well. > > > *** Packages of interest status: > > mod_perl : 1.29 > > mod_perl2 : 2.000003, 2.000005 > Speaking of clean trees, that can't be good. > you have multiple versions of mod_perl2 installed which almost certainly means > that you'll get a mix match between .pm and .so files. I'd clean that up > My IHP provides a large number of .so's in the include directory, and I just let the mod-perl 2.0.4 that I built exist next to the 2.0.3 from my IHP's original setup. This has never caused any problems in the past. (httpd.conf calls out the 2.0.4.so.) But on your advice I will rename the 2.0.3 with an extra ".hide" after the ".so", and retry the thing as soon as I get back to my development machine next Monday. FWIW I'm startled by the "2.000005" but I assume that's because the last thing built was the _20081223052020 on the recommendations of the mod_perl web site. > > FWIW, you really shouldn't install your own perl into /usr/local/bin/perl on > FreeBSD you should put yours somewhere else. > There is great value to me in having a single perl that is used for all applications, rather than a "my perl" and "their perl" and "the perl used by that other gang over there". For example, commonality of use of Berkeley DBs by perl programs from various sources discourages having multiple Perl binaries in use. (Older perl's are still around for reference but nothing uses them on our site.) >
