Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 11:19:42AM +0100, Steve Hay wrote: > Why isn't the typemap file distributed as part of ExtUtils-MakeMaker? typemap is very specific to the version of Perl, or so it is said. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ You're more radiant than a memory of breathtaking ecstasy.
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 09:35:55AM +0100, Steve Hay wrote: > Somehow, it has contrived to disappear! It always used to exist there, > which is why it didn't occur to me to check :-( I must have lost it > somewhere along the line when shoe-horning earlier MakeMaker's into place. Possibly you deleted the ExtUtils/ directory? > Having now restored that file, the patch above does indeed fix it for me. Yay! -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ I need a SHOWER a BURGER and some ROBOTS, STAT! -- http://www.angryflower.com/allrigh.gif
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 08:46:27AM +0100, Steve Hay wrote:
> I tried changing the s/// to:
>
>$string =~ s{ \$\(INST_DYNAMIC\)}{}g;
>$string =~ s{ \$\(INST_BOOT\)}{}g;
>
> (I've dropped the trailing spaces in the patterns), which produced:
>
> dynamic :: $(FIRST_MAKEFILE)
>$(NOECHO) $(NOOP)
>
> in the Makefile as desired, but now the build process fails with this error:
>
> fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
That's odd. Does that file exist? If not, where is your typemap file?
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
I'm exploring my nipples.
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Fri, Aug 01, 2003 at 11:35:47AM +0100, Steve Hay wrote:
> =
> # --- MakeMaker dynamic section:
> ## $(INST_PM) has been moved to the all: target.
> ## It remains here for awhile to allow for old usage: "make dynamic"
> #dynamic :: Makefile
> dynamic :: Makefile
>@$(NOOP)
> =
>
> while the corresponding section from the 6.12 build contains this:
>
> =
> # --- MakeMaker dynamic section:
> ## $(INST_PM) has been moved to the all: target.
> ## It remains here for awhile to allow for old usage: "make dynamic"
> dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
>$(NOECHO) $(NOOP)
> =
>
> If that's relevant, then the latter looks more likely to be correct,
> doesn't it? Perhaps MM 6.06+ has correctly fixed a bug in MM 6.05, and
> the only problem here is that libapreq was previously relying on that bug?
The problem is likely the MY::dynamic hack in c/Makefile.PL. 6.05 and
previous had this:
dynamic :: Makefile $(INST_DYNAMIC) $(INST_BOOT)
6.06_01 and up have this
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
for some reason, MY::dynamic is trying to lop off everything after "Makefile"
and moving $(INST_DYNAMIC) to a different target in MY::top_targets.
(Where INST_BOOT is run from, I dunno). But dynamic no longer matches
/Makefile/ so the hack fails and you wind up with INST_DYNAMIC built from
two places.
Coupled with the fact that its set LINKTYPE 'static' with a comment
"problems with things finding libareq.so, sort out later" leads me to
believe this was a work around a MakeMaker bug.
Chaning s/(Makefile\s+).*/$1/g to
s{ \$\(INST_DYNAMIC\) }{}g;
s{ \$\(INST_BOOT\) }{}g;
should "fix" the symptoms by restoring the hack for a quick fix.
For a longer term solution, try removing the MY::dynamic and
MY::top_targets overrides entirely, plus changing LINKTYPE to 'dynamic' and
see what happens.
It would be nice if someone could dig through libapreq's version history
and figure out when and why this hack was put in.
--
WOOHOO! I'm going to Disneyland!
http://www.goats.com/archive/980805.html
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Fri, Aug 01, 2003 at 09:05:55AM +0100, Steve Hay wrote: > I just tried MM 6.13: that made no difference. > > Then I tried the snapshot (taken at 01 Aug 2003 07:55 UTC): that failed > loads of its own tests, but made no difference to the libapreq build > process. Oh yeah, I didn't update the snapshot. Thanks for the reminder. -- You can't control the universe with a jar of red pepper. http://www.goats.com/archive/981004.html
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Fri, Aug 01, 2003 at 10:03:20AM +0100, Steve Hay wrote:
> >This bug evidently goes back a long way: MM 6.06_02 fails in the same
> >way as 6.13.
> >
> >I tried to use MM 6.06_01, but it wouldn't build itself ("don't know
> >how to make 'C:\perl5\libNAME'"). Instead, I knife-and-forked it into
> >place, but when I tried to use it to build libapreq, I just got the
> >same error again - "don't know how to make 'C:\perl5\libNAME'".
>
> OK, I've got MM 6.06_01 building now (it was generating broken Makefiles
> -- needed to change DIRFILESEP from \ to ^\, and fill in the missing
> *PERLSAFE macros), and the bad news is that it doesn't build
> libapreq-1.2 either! I still get the "unresolved external symbol
> boot_libapreq" error.
>
> So it's one of the many changes between 6.05 and 6.06_01 that broke it.
Well, that narrows it down quite a bit.
Which version of mod_perl and Apache is this against and *exactly* what do
I have to do to exercise this bug? I haven't built mod_perl in a long time.
--
I'll tell you what beats voodoo every time, a big ass knife.
-- "Overkill" Battlebot driver
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Thu, Jul 31, 2003 at 01:27:01PM -0700, Michael G Schwern wrote: > I'm glad you guys got it working, but there's still the problem of why > MakeMaker's behavior changed. Since I tend not to touch the XS building > code much its likely a bug. Try the snapshot on makemaker.org. I just > fixed a minor issue with argument passing in recursive builds. Actually, try 6.13. That snapshot had a bug in it. -- Abandon failing tactics.
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Thu, Jul 31, 2003 at 03:23:36PM +0100, Steve Hay wrote: > This patch finally fixes it for me: I'm glad you guys got it working, but there's still the problem of why MakeMaker's behavior changed. Since I tend not to touch the XS building code much its likely a bug. Try the snapshot on makemaker.org. I just fixed a minor issue with argument passing in recursive builds. If I could see the Makefiles from 6.03 and 6.12 I might be able to figure out what's different. Also, if you could try various alpha versions between those two, show the Makefiles and whether or not they exhibited the behavior that would help alot in narrowing it down. -- You're the sickest teenager I've ever set my wallet on.
DBI->connect_cached not playing with Apache::DBI
An Ima::DBI user recently pointed out that DBI->connect_cached is not using
Apache::DBI like DBI->connect does and DBI->connect_cached has slightly
different semantics from Apache::DBI.
sub connect_cached {
# XXX we expect Apache::DBI users to still call connect()
my ($class, $dsn, $user, $pass, $attr) = @_;
($attr ||= {})->{dbi_connect_method} = 'connect_cached';
return $class->connect($dsn, $user, $pass, $attr);
}
There's a problem with the logic in the comment above. Apache::DBI is
supposed to be transparently used by DBI. So, in effect, there are no
Apache::DBI users. More pragmatically, I write a lot of dual-natured
programs. Stuff that might be run under Apache::Registry or might be
a stand-alone. I like using connect_cached() because I don't have to
store a global $Dbh, but I thought I was getting the performance boosts of
Apache::DBI where applicable.
So I guess the question is, why doesn't DBI->connect_cached just defer to
Apache::DBI->connect?
--
This sig file temporarily out of order.
Re: problems on OS X
On Mon, Apr 29, 2002 at 12:39:32AM +1000, Ken Williams wrote:
> I sent a message earlier today saying that this patch seems to help
> things, but I just noticed something disturbing. After hand-applying
> this patch to my CWD.pm from 5.6.1, I ran a 'perl Makefile.PL' for a
> different module (Apache::SSI), and it created the Makefile not in the
> current directory, but in my *home* directory! Weird. I don't know why
> it happened yet, but obviously this isn't a good thing.
Likely something passed chdir() an undef or '' which means "chdir to
$ENV{HOME}". Unfortunate shell holdover. Likely the pwd/chdir combination
in eval_in_subdirs().
--- lib/ExtUtils/MakeMaker.pm 24 Apr 2002 05:30:36 - 1.44
+++ lib/ExtUtils/MakeMaker.pm 29 Apr 2002 04:06:20 -
@@ -79,7 +79,8 @@
sub eval_in_subdirs {
my($self) = @_;
use Cwd qw(cwd abs_path);
-my $pwd = cwd();
+my $pwd = cwd() || die "Can't figure out your cwd!";
+
local @INC = map eval {abs_path($_) if -e} || $_, @INC;
push @INC, '.'; # '.' has to always be at the end of @INC
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
You're the sickest teenager I've ever set my wallet on.
