|
in reply to ExtUtils::MakeMaker, APR::UUID or Perl problem?
Since it seems there's no problem with APR
in stand-alone mode, it would be good to narrow
down why it's interfering with WriteMakefile. A couple
of simple possibilities come to mind that would be
worth checking:
-
Somehow APR affects printing in general. Does the following
work in generating a non-zero sized file?
use APR;
open(FH, '>test.txt') or die "Cannot open test.txt: $!\n";
print FH "This is some text\n";
close(FH);
- APR somehow interferes with the arguments passed to
WriteMakefile. Does the following print (to STDOUT)
the named MakeMaker parameters?
use ExtUtils::MakeMaker;
use APR;
my $r = WriteMakefile(
NAME => 'Handel',
VERSION_FROM => 'lib/Handel.pm',
AUTHOR => 'Christopher H. Laco',
ABSTRACT => 'Simple ecommerce framework',
);
for my $key (qw(NAME VERSION_FROM AUTHOR ABSTRACT)) {
print "$key -> $r->{$key}\n";
}
|
Re^2: ExtUtils::MakeMaker, APR::UUID or Perl problem?
by jk2addict (Chaplain) on Dec 04, 2005 at 16:57 UTC
|
First example: Succeeds. test.txt contains the text.
Second example: Succeeds & Fails. It prints the key/value pairs to STDOUT, but the resultant Makefile is 0 bytes.
| [reply] |
Re^2: ExtUtils::MakeMaker, APR::UUID or Perl problem?
by jk2addict (Chaplain) on Dec 04, 2005 at 17:51 UTC
|
I don't think it's just interfering with WriteMakefile, but instead either other XS loading or file writing.
In the dist in question, I have a bunch of tests that read/write to sqlite databases using DBD::SQLite. I commented out the APR load in Makefile.PL to get a complete Makefile. Then I started running the tests.
All of the sqlite tests were failing with strange errors, corrupt db, locked db, full db, etc. In my core module, Handel.pm, I commented out the same APR::UUID eval statement I use in Makefile.PL to find the appropriate uuid module.
As soon as I commented out APR::UUID, all of my sqlite tests passed. If I uncomment it, they fail again.
So, it's not just EU::MM being borked, but other things as well. I don't know enough to know whether it's effecting the loading of XS in other modules, or some read/write process being borked.
| [reply] |
|
|
That sounds right about it being a more global problem.
One place that something specific to openbsd arises is in
APR.pm, in defining the dl_load_flags sub. I'm not sure
of the background behind this - probably someone on the
modperl mailing list would be able to help.
Is this Perl built with
ithreads support? If so, the comment in
README.openbsd of the perl sources about needing to
upgrade to Perl 5.8.7 may be relevant.
| [reply] |
|
|
test:~$ perl -V
Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
Platform:
osname=openbsd, osvers=3.8, archname=i386-openbsd
uname='openbsd'
config_args='-dsE -Dopenbsd_distribution=defined'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultipl
+icity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
| [reply]
[d/l] |
|
|
BEGIN {warn 'using custom APR'};
and rerun perl -Ilib Makefile.PL, I get the correct full Makefile. Removing that BEIGN statement make the Makefile 0 bytes again.
If I comment out the line:
# sub dl_load_flags { DL_GLOBAL }
I still get an empty Makefile. There be demons in there.
| [reply]
[d/l]
[select] |
|
|
print 'foo';
My Makefile gets created. So, it seems to point to an APR/XS I/O buffering issue outside of MP.
| [reply]
[d/l] |
|
|
|
|
