Christopher H. Laco wrote:
> I'm headed out for the day, so I apologize for the email-and -un. I
> posted this last night to PerlMonks, and I'll post it to the EU::MM list
> when I get home:
> 
> http://perlmonks.org/?node_id=513773
> 
> Long story short, I got reports that perl Makefile.PL for my dist was
> producing a 0 byte Makefile. After whittling it down, I found that any
> encantation of use/require/eval ''/eval{} of APR::UUID in my Makefile.PL
> was causing ExtUtils::MakeMaker to spit out a 0 byte Makefile; only on
> OpenBSD. Linux/FreeBSD/win32 worked fine.
> 
> Removing the probe for APR::UUID solved the problem.
> 
> At this point, I have no idea what is going on, or even where the
> problem is (EU::MM, Perl, XS, or APR::UUID). Someone on #catalyst
> mentioned that there are Config/dl_load/ ne 'openbsd' bits in APR.xs
> that may or maynot be just a coincedence.
> 
> Anyone else have any ideas?
> 
> When I get home, I'm going to make a bare bones dist and Makefile.PL for
> testing purposes. Luckily, the reporter of the problem was kind enough
> to seutp a test account for my on the mahcine in question.
> 
> It has MP 2.0.2, OpenBSD 3.8 RELEASE, perl 5.8.6, and EU::MM 6.30.
> 
> Thanks,
> -=Chris

Just to keep the list up to date, and recap what has been found:

The following Makefile.PL produces a 0 byte Makefile under MP2.0.2,
OpenBSD 3.8-RELEASE, perl 5.8.6:

> use ExtUtils::MakeMaker;
> use APR;
> my $r = WriteMakefile(
>     NAME         => 'Handel',
>     VERSION_FROM => 'lib/Handel.pm',
>     AUTHOR       => 'Christopher H. Laco',
>     ABSTRACT     => 'Simple ecommerce framework',
> );

On a whim that it might be a double loading of APR issue between
Makefile.PL, and EU::MM eval-ing my Handel.pm, I changed the Makefile.PL
to this:

> use ExtUtils::MakeMaker;
> use APR;
> my $r = WriteMakefile(
>     NAME         => 'Handel',
>     VERSION      => '0.28',
>     AUTHOR       => 'Christopher H. Laco',
>     ABSTRACT     => 'Simple ecommerce framework',
> );

That still creates a 0 byte Makefile.

Adding a print statement to this makes it work:

> use ExtUtils::MakeMaker;
> use APR;
> print 'foo';
> my $r = WriteMakefile(
>     NAME         => 'Handel',
>     VERSION_FROM => 'lib/Handel.pm',
>     AUTHOR       => 'Christopher H. Laco',
>     ABSTRACT     => 'Simple ecommerce framework',
> );

Just to reinforce that notion, if I add this to APR.pm:

> BEGIN {warn 'using custom APR'};

I get the full Makefile.

Commenting out:

> sub dl_load_flags { DL_GLOBAL }

or it's use constant DL_GLOBAL has an effect on the problem.

No incantations of use/require, eval{}. eval '' solve the problem.

I've also noted that I have massive SQlite test failures on this box
with things like:

> DBD::SQLite::db do failed: database is full(1) at dbdimp.c
> DBD::SQLite::db do failed: database schema has changed(1)
> DBD::SQLite::db do failed: no such table:

that immediately went away when I removed use APR from my main module.
...only on OpenBSD.


At this point, the level of magic required to further identify and fix
this issue is way above my skill level. Unless anyone has any further
ideas, it looks like I need to refrain from using APR [outside of
Apache/MP] in this platform.

My real concern is what else XS/IO related is borked in this kind of
scnerio...

Thanks,
-=Chris




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to